Is It a Good Idea to Build an HLS Tool on Top of MLIR? Experience from Building the Dynamatic HLS Compiler

Abstract: When the MLIR project was first introduced, it promised to address the issues that the HLS community had with the LLVM project. But is this really the case, and is MLIR the "right"/"best" compiler infrastructure for HLS? We here share our experiences based on the development of Dynamatic (github.com/EPFL-LAP/dynamatic).

• The paper demonstrates that MLIR’s dialects enable significant IR customization for robust dataflow circuit generation in HLS.
• It details how MLIR’s edge annotation deficiencies and non-optimal SSA representations complicate hardware-specific IR transformations.
• The study highlights integration challenges and frontend limitations, underscoring critical improvement areas for MLIR-based HLS toolchains.

Evaluation of MLIR as a Foundation for HLS Tooling: Lessons from Dynamatic

Introduction

This essay provides a critical evaluation of using Multi-Level Intermediate Representation (MLIR) as a compiler infrastructure for High-Level Synthesis (HLS) tools, drawing extensively from the experience of developing the Dynamatic HLS compiler ["Is It a Good Idea to Build an HLS Tool on Top of MLIR? Experience from Building the Dynamatic HLS Compiler" (2603.19856)]. While MLIR offers formal mechanisms for customizable IRs and transformation passes that are highly attractive for hardware compiler research, this analysis elucidates both its strengths and persistent limitations, particularly as they pertain to the requirements of HLS and circuit-centric workflows.

MLIR versus LLVM for IR Customization in HLS

MLIR was initially proposed as a remedy for the rigidity of LLVM IR in the context of HLS. LLVM IR forces HLS toolchains to implement ad hoc, difficult-to-maintain custom IRs due to limited circuit expressiveness. In contrast, MLIR introduces the notion of dialects and operations, enabling direct encoding of both high-level software abstractions and circuit semantics. This architectural flexibility is a significant practical advantage, increasingly leveraged by tools such as Dynamatic for robust dataflow circuit generation.

Figure 1: Dynamatic aims to translate software IR (left) to dataflow circuit (right), exemplifying the IR flexibility enabled by MLIR dialects.

The modularity of MLIR aids academic developers, particularly those without extensive software engineering backgrounds, in constructing cleaner, maintainable HLS tooling that concentrates on hardware-specific features. Automated routines for IR object manipulation, textual representation, and dialect composition further reduce development overhead.

Critical Limitations of MLIR for HLS Workflows

Despite its formal strengths, MLIR exhibits several fundamental limitations that complicate its use in open-source HLS tools and hardware compilation flows.

Edge Annotation Deficiency

A persistent issue is MLIR's inability to attach attributes directly to values, which represent edges in the IR graph. Many HLS tasks, such as memory dependency tracking and profiling, require edge-specific metadata. In Dynamatic, memory dependencies between load and store operations must be encoded in convoluted formats—node-centric annotations and external CSV files—since edge-level information cannot be natively attached.

This workaround impedes standardization and impairs the fidelity of behavioral constraints required for correct and optimized circuit scheduling. The lack of edge annotation is problematic not only for hardware but also for advanced software compiler analyses (e.g., branch probabilities).

SSA and Block Arguments: Non-Optimal IR Representations

MLIR's abandonment of explicit $\phi$ nodes in favor of block arguments complicates software-circuit translation. Conditional assignments in software must be converted into hardware multiplexers, but block arguments are not operations and lack direct producers, preventing pattern rewriting from being locally defined and complicating input tracking for multiplexers.

This SSA representation diverges from LLVM's more operational $\phi$ node semantics, contributing to awkward, non-local transformation logic in Dynamatic and similar HLS tools.

Fragmentation and Integration Challenges

MLIR was envisioned to alleviate fragmentation by facilitating transformation pass reuse via dialect interoperability. In practice, project integration remains cumbersome when dialects are implemented in separate repositories tracking divergent LLVM/MLIR versions.

Figure 2: Integrating two MLIR projects is challenging, as differing dependencies and API versions impede transformation pass composition.

Dynamatic's own handshake-to-XLS dialect conversion is subject to frequent breakage as external projects update independently, illustrating the fragility and non-scalability of current MLIR-based HLS ecosystem integration.

Front-End Limitations for C/C++ IR Generation

There is currently no competitive C-to-MLIR frontend that matches the optimization granularity of LLVM-based approaches. Existing tools (e.g., Polygeist, CIR) provide limited optimization and semantic fidelity. As a result, most MLIR-based HLS flows ultimately lower to LLVM IR, resuscitating the very limitations MLIR was designed to eliminate. This dependency leads to complex workarounds and prevents MLIR from serving as a truly independent, first-class infrastructure for HLS and hardware-centric compilation.

Broader Implications and Recommendations

The issues highlighted in the development of Dynamatic are not exclusive to HLS tools—they are generalizable to all MLIR-based compilers that require edge-specific metadata, robust SSA modeling, and cross-project integration. Addressing these limitations would improve interoperability and expressiveness for both software and hardware compilation communities, enabling MLIR to fulfill its original promise more completely.

Conclusion

MLIR's formalism, modularity, and dialect architecture are beneficial for HLS research tooling, lowering development barriers and encouraging specialization. However, practical issues around edge annotation, SSA modeling, project integration, and frontend competitiveness necessitate fragile workarounds and limit MLIR's utility. Ongoing improvements targeting these foundational weaknesses are critical for future HLS tool evolution and for MLIR's viability as a universal compiler infrastructure.