关键词：MLIR、HLS、高级综合、Dynamatic、编译器基础设施、数据流电路
当前，LLVM 是高级综合（HLS）工具的主流底层框架。然而，其固有的中间表示（IR）难以定制化地表达电路语义。MLIR 则承诺通过其自定义方言机制来解决这一问题。
- 论文：Is It a Good Idea to Build an HLS Tool on Top of MLIR? Experience from Building the Dynamatic HLS Compiler
- 链接：https://arxiv.org/pdf/2603.19856
- 代码仓库：github.com/EPFL-LAP/dynamatic
- 项目文档：https://epfl-lap.github.io/dynamatic/
本文基于动态调度 HLS 编译器 Dynamatic 的长期开发实践，系统评估在 MLIR 之上构建 HLS 工具的可行性。
研究表明，MLIR 凭借其模块化架构、降低定制 IR 开发成本以及适配学术团队开发流程等优势，能够有效支撑数据流电路的表示与优化。然而，团队在工程实践中也发现了 MLIR 存在的四大核心局限：
- MLIR 数值无法为图边附加属性，难以建模内存依赖与控制流边信息；
- 使用块参数替代显式节点的设计，增加了软件到硬件转换时多路选择器的实现难度；
- 第三方 MLIR-HLS 项目因 LLVM 版本不兼容，存在严重的集成碎片化问题；
- 现有 C 语言前端优化能力不足，导致项目仍需依赖 LLVM 并采用复杂的变通方案。
这些问题并非 HLS 领域独有，对通用 MLIR 编译器开发同样具有参考价值。本文旨在总结工程实践经验，为 MLIR 社区的优化以及未来 HLS 工具基础设施的选型提供关键依据。
Processor Architecture Laboratory
本文目录
- 一、引言
- 二、背景
- 三、学术环境下构建基于 MLIR 的 HLS 编译器
- 四、MLIR 对开源 HLS 项目的局限及 Dynamatic 中的案例分析
- 4.1 MLIR 数值不适合建模图边
- 4.2 块参数对 HLS 转换是否便捷？
- 4.3 我们解决了软件碎片化问题吗？
- 4.4 是否有优质的 HLS C 前端助力新型 HLS 工具开发？
- 五、超越 HLS 的普适性
- 结论
- 参考文献
一、引言
LLVM 项目[1]是众多开源与商用高级综合（HLS） 工具[2-7]的基础，这类工具负责将高级软件代码编译为寄存器传输级（RTL） 电路。
然而，LLVM 并非 HLS 工具的理想选择[8]：其 IR 无法定制化地表示电路结构，迫使 HLS 工具不得不自行开发难以复用的定制化电路 IR。
MLIR [8,9]承诺解决这一问题：它提供了一套标准化的方式来定义、创建、分析和转换自定义 IR（称为方言，Dialect）。借助 MLIR，HLS 开发者能够突破 LLVM IR 的刚性限制，既能定义支持高层变换的高级 IR，也能定义具备精确电路语义的底层 IR。对于自定义 IR，MLIR 提供了创建、操作 IR 对象、转储与解析文本格式等默认 C++ 接口，这大幅降低了实现开销，并促进了基于 MLIR 的工具之间的互操作性。
作为 Dynamatic[4,5]——一款基于 MLIR 的 HLS 工具——的核心开发者，我们认可并充分利用了 MLIR 的上述优势。但同时，我们也发现 MLIR 的部分特性为开发带来了阻碍。
_本文旨在分享我们在 MLIR（版本 d8eb4ac）开发实践中遇到的问题，涵盖 IR 定义、分析、变换，以及不同基于 MLIR 的 HLS 项目间的集成。我们认为这些观察具有普适性，并非仅针对基于 MLIR 的 HLS 项目。希望这些发现能为 MLIR 社区带来新的思考与讨论，并帮助开发者为未来的 HLS 工具做出更合理的决策。
二、背景
本节简要介绍 MLIR 与 Dynamatic 的相关背景知识。
MLIR[9]是一套编译器基础设施，支持定义自定义 IR（方言）与变换 Pass。IR 由操作（Operation）构成，操作会消费与产生数值（Value）。
Dynamatic 用于生成数据流电路（Dataflow Circuits）[10,11]，这类电路由指令粒度的数据流单元通过握手通道连接而成；数据被封装在令牌（Token）中，通过握手通道传输。在数据流电路中，操作只要输入有效就会立即执行。因此，Dynamatic 生成的动态调度电路，在控制流或内存访问模式不可预测的场景下具备性能优势[12-14]。Dynamatic 是基于 MLIR 的编译器：它在专用的握手协议方言（Handshake Dialect） 中，将数据流单元与通道分别表示为 MLIR 的操作与数值。
Dynamatic 已从研究原型逐步走向成熟：它成为大量学术论文的基础实现[11-37]，其中多数成果已整合到主 HLS 流程中[11-13,15-16,21-25,28,32]。我们在多个技术会议上开展了相关教程与技术分享[5,38]。Dynamatic 主干分支每月合并约 30 个拉取请求（PR），每个 PR 都通过自动化 CI/CD 流水线进行监控，以避免引入编译错误或性能退化。经验不足的开发者提交的代码贡献，会收到详细的评审与反馈。
三、学术环境下构建基于 MLIR 的 HLS 编译器
我们认可在学术场景中，以 MLIR 为基础开发 HLS 项目具备显著优势。Dynamatic 主要由学生开发者完成，团队成员多为电气工程背景，并非专业软件开发人员，通常不熟悉软件工程最佳实践。
MLIR 帮助我们克服了这一挑战：它直观展示了复杂面向对象编程架构的实际工作方式，其模块化设计启发我们打造了易于理解、结构清晰的工具。这些优势让我们能将更多开发精力投入到 HLS 专属功能的实现中。
然而，我们也发现 MLIR 的部分特性为 HLS 工具的开发带来了阻碍，下文将对此进行详细阐述。
四、MLIR 对开源 HLS 项目的局限及 Dynamatic 中的案例分析
本节讨论在 MLIR 之上构建 Dynamatic HLS 工具时遇到的具体问题。
4.1 MLIR 数值不适合建模图边
将软件中间表示或电路建模为图是行业通用做法。在这种模型中，部分信息天然属于节点，另一部分则属于边。MLIR 允许在操作（节点）上附加属性，但无法为表示操作间数据流依赖的 MLIR 数值（Value）附加任何属性。这给需要在边上标注信息的硬件高级综合带来了挑战。
案例 1：内存依赖
store3与下一次迭代的load2之间存在潜在的写后读（RAW） 依赖。这类依赖通常由软件 IR 分析得到，需要在存储与加载操作间的依赖边上标注依赖距离，并作为 HLS 调度约束以保证操作执行顺序正确。由于 MLIR 不允许为边或操作对添加注解，这类信息只能以非标准、不直观的方式表示。
Dynamatic 通过别名分析与多面体分析确定内存访问间的依赖对。为在 HLS 流程中保留该信息，Dynamatic 为每个操作分配唯一名称，在整个 HLS 流水线中维护该名称，并以可读性差的格式表示依赖关系。为保证正确性，还需确保所有变换都不破坏操作名称的成对有效性，这增加了实现的复杂性与出错风险。
图 1 展示了一段 C 程序与对应 MLIR 代码的片段，直观说明了在 MLIR 中标注边信息的棘手之处。
案例 2：软件性能剖析记录
软件性能剖析常用于 HLS 中确定操作执行次数与序列（例如用于早期性能评估或对高频执行代码做针对性优化）。尽管这类信息天然属于基本块间的控制流边，但 MLIR 中没有标准化方式为控制流边添加注解。
Dynamatic 依赖软件性能剖析识别需要优先优化的高频执行循环。这类信息本可记录在分支单元的输出边上，但由于 MLIR 不支持数值注解，Dynamatic 只能通过外部 CSV 文件存储该信息。
MLIR 若能完善边注解支持，将有效解决这类问题。
4.2 块参数对 HLS 转换是否便捷？
在 HLS 流程中，需要将软件表示转换为电路，尤其要将静态单赋值（SSA） 的 φ 节点（表示条件赋值）转换为多路选择器。在 MLIR 中，这一转换是否直观？
案例 3：将块参数转换为多路选择器
图 2a 展示了 ControlFlow 方言（MLIR 内置的、用于表示串行程序的方言）中的一个基本块：它以标识
bb1开头，携带块参数（%3, %4），以条件分支结尾。MLIR 用这类块参数表示 φ 节点。这种表示方式在软件转电路的过程中存在以下问题：
(a) 块参数是无生产者的数值；
(b) 分支指令收集输出数值，但这些数值与后继基本块无直接关联。
第一个问题导致模式重写难以适配该转换——因为没有可匹配的操作。第二个问题让多路选择器输入的定位变得不必要地复杂：与 LLVM 的 φ 节点（可直接获取其他基本块的输入数值）不同，MLIR 中需要先定位父基本块、分支指令，再获取分支输入的数值。
Dynamatic 使用 MLIR 的模式重写完成该转换，但该方案并非最优——因为重写需要作用于整个函数，违背了局部重写规则的设计初衷。
4.3 我们解决了软件碎片化问题吗？
MLIR 承诺通过让编译器项目复用彼此的变换 Pass，解决软件碎片化问题。这在 MLIR 官方仓库内或许成立，因为维护者对模块协同方式有统一规划。但大量项目并未合入 MLIR 上游，例如 CIRCT、Polygeist、Dynamatic、MLIRAIE等。我们能否无缝集成这些项目？
案例 4：为两个 GitHub 仓库维护的方言实现变换 Pass
假设我们要实现一个新的 MLIR Pass，将方言 A 转换为方言 B。若方言 A、B 的实现依赖两个 API 不兼容的 LLVM 项目（MLIR 版本不一致导致编译错误），该功能在理论上无法实现。
Dynamatic 实现了一个定制化转换 Pass，将握手协议方言转换为 XLS MLIR 方言。由于我们无法持续将 Dynamatic 的 LLVM 版本与每日更新的 XLS 保持同步，该功能极易过时失效。
图 3 展示了两个基于 MLIR 项目的简化架构，这些项目分别实现了方言 A 与方言 B，集成它们具有挑战性。
4.4 优质 C 前端的缺失对新型 HLS 工具开发的制约
HLS 前端负责将 C 代码转换为中间表示（IR）、执行 IR 优化，并为后续的电路综合标注关键信息。那么，MLIR 生态中是否存在一个能够满足所有需求的成熟 C 语言前端？
现状分析：C 到 MLIR 转换的探索
目前，已有一些项目致力于实现 C 语言到 MLIR 的转换：
* Polygeist：将 C 语言的抽象语法树（AST）转换为 MLIR 中的结构化控制流（SCF）方言。
* Clang CIR：作为 Clang 项目的一部分，旨在将 C AST 转换为专门为 C 语言语义建模的 CIR 方言。
然而，这些方案在单独使用时，通常无法提供与成熟 HLS 工具链相匹配的、细粒度的 IR 优化能力，其整体竞争力仍弱于基于 LLVM IR 的传统 HLS 编译器前端。
根本挑战：对 LLVM 优化能力的路径依赖
由于 LLVM 提供了一套经过充分验证的、成熟的 IR 优化基础设施，大多数基于 MLIR 的编译器项目最终都会选择将自定义方言降级（lower）为 LLVM IR，以复用其强大的优化能力。
这种策略虽然降低了在 MLIR 框架内重复实现同类优化的开发成本，但也带来了一个显著的副作用：它将 MLIR 原本试图规避的 LLVM IR 的所有局限性，重新引入了编译流水线。
鉴于现有 MLIR C 前端的竞争力不足，Dynamatic 在开发中仍需要依赖 LLVM IR 来完成前端处理。这迫使开发者采用定制化方案来实现诸如内存分析和从原始 C 代码推导数组大小等任务。这些任务在僵化的 LLVM 框架中难以优雅实现，却本应是 MLIR 灵活编译流程可以自然支持的。
五、超越 HLS 的普适性启示
尽管本文的讨论基于 Dynamatic 在 HLS 领域的特定实践，但我们认为所揭示的问题具有广泛的普适性，并非仅针对基于 MLIR 的 HLS 项目：
- 边信息建模的通用性：无论是软件还是硬件编译器，都频繁依赖边专属信息（如内存依赖、分支概率），因此都会受到 4.1 节所述 MLIR 当前表达能力限制的影响。
- SSA 形式挑战的延伸：4.2 节讨论的 SSA 挑战虽然主要面向硬件领域，但 IR 中缺少
phi节点同样会给软件编译器中基于使用-定义链和数据依赖关系的分析与优化带来麻烦。 - 生态碎片化的普遍性：4.3 节所述的软件栈碎片化与版本同步问题，完全通用，适用于所有依赖多层、多项目 MLIR 生态的编译器开发。
- 前端生态影响的广泛性：所有以 C 语言为主要输入源的编译流程，都会受到 4.4 节所述 C 前端生态成熟度不足的影响。
因此，解决这些问题将惠及整个 MLIR 社区，推动其成为更健壮的编译器开发框架。
结论
本文基于 Dynamatic 编译器的深度开发实践，系统性地总结了在 MLIR 框架上构建高层次综合（HLS）工具所面临的核心挑战。
MLIR 通过其可扩展的方言机制和模块化架构，为硬件编译器提供了比 LLVM 更为灵活的中间表示支撑，显著降低了学术环境中复杂编译器项目的开发门槛。然而，在实际应用中，MLIR 在边信息建模、SSA 表示向硬件语义的转换、跨项目代码复用与生态协同、以及 C 语言前端生态的成熟度等方面，仍存在明显局限。这些问题迫使开发者采用大量非标准且脆弱的变通方案，影响了工具链的长期可维护性与可扩展性。
作者指出，上述挑战不仅局限于 HLS 领域，对更广泛的软硬件协同设计与编译器工程同样具有重要的参考价值。通过分享这些实践经验，本文旨在引发 MLIR 社区对基础设施设计的深入讨论，共同推动未来编译器工具链在核心表达能力、模块化协作以及前端完备性等方面的持续演进，从而为构建更高效、可复用的开源硬件编译生态奠定坚实基础。
Processor Architecture Laboratory
* https://github.com/EPFL-LAP/dynamatic
* https://epfl-lap.github.io/dynamatic/
* https://www.epfl.ch/labs/lap/
参考文献
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/archives/27237
