🔁 MLIR - Gate modifiers framework

[burgholzer]

Background

OpenQASM 3 introduces gate modifiers to concisely express transformations on quantum gates/blocks (see https://openqasm.com/versions/3.0/language/gates.html#quantum-gate-modifiers). Common modifiers include inv (adjoint), pow(r), and ctrl/negctrl.

In our stack today:

• Controls: handled lazily via the unitary operation interface in both MQT Core IR and MLIR. No separate modifier op required right now.
• Inversion: supported eagerly in MQT Core IR (see Operation::invert / Operation::get_inverted), but not yet modeled in MLIR and not available in a lazy evaluation scheme
• Power: not supported in either MQT Core IR or MLIR, though the OQ3 parser recognizes the syntax. Support for adding that to the MQT Core IR is tracked in ✨ Support for the powering modifier of OpenQASM 3.0 #27

MLIR concept of “modifiers”

A quick LLM summary about the general concept:
In MLIR, gate modifiers can be represented using one or more of the following approaches:

• Op attributes on the modified op (e.g., mqtref.gate {inv} or {pow = r}) with canonicalizations that eliminate attributes by rewriting to equivalent ops.
• Wrapper ops that own a region containing the target op(s) (e.g., mqtref.inv { ... }), enabling region-level transforms like reversing order and inverting contained ops.
• Function- or region-level modifiers for block-wise semantics (e.g., to invert a block of unitary ops), verified via traits (e.g., "unitary-only region").

We’ll introduce a single, consistent framework that:

• Defines a common modifier abstraction.
• Verifies legality via traits/interfaces (e.g., only unitary ops permit inv/pow).
• Provides canonicalizations to eliminate modifiers when possible (e.g., inv(Rz(θ)) -> Rz(-θ)).

Problem

We lack a unified representation for gate modifiers in MLIR; inversion isn’t modeled yet, and pow is missing entirely. We need IR constructs, verifiers, and canonicalizations consistent with frontend semantics and downstream lowerings.

Proposal:

• Introduce modifier attributes and wrapper ops in MQTRef:
  • Attributes: inv: unit, pow: <integer|float>, reserved control (deferred).
  • Wrapper ops: mqtref.inv (region-level), optional mqtref.power if region application is needed.
• Define traits/interfaces that mark ops and regions as unitary-only and thus eligible for modifiers.
• Add canonicalizations and legality checks (e.g., prohibit pow on non-unitary ops, allow inv only on unitary sequences).
• Provide lowering guidance for inv and pow (see sub-issues below): eager rewrites where possible; otherwise preserve modifier until a later pass.

Examples:

• Attribute form on a single op

  // Conceptual attribute usage (to be legalized by canonicalizations)
  %q = ... : !mqtref.qubit
  mqtref.rz %q, %theta {inv} : (!mqtref.qubit, f64) -> ()

• Region form for inverse of a block

  mqtref.inv {
    // quantum-only region
    mqtref.h %q : !mqtref.qubit
    mqtref.cz %q0, %q1 : !mqtref.qubit, !mqtref.qubit
  }
  // Canonicalization: reverse order and invert each op

Acceptance criteria:

• Common modifier abstraction exists (attributes + region wrapper), with verifiers and traits.
• Canonicalizations for standard gates (e.g., adjoint of rotations, power-of-phase simplifications) are defined at framework level for reuse.
• Documentation added to docs/mlir.md covering the modifier model.

[DRovara]

Some thoughts on this:

• I'm not against using modifier-attributes AND regions at the same time, but it should be a conscious decision. Using both could very well lead to an increase in optimization efforts (unless all cases can be reduced by some canonicalizations)
• We can even implement some custom assembly format for these modifiers to make them look more natural, e.g. mqtref.rz(%theta) %q0 inv or maybe even something like mqtref.rz**[%pow](%theta) %qo

[burgholzer]

Yeah, we should definitely try to avoid making it harder for optimizations.
I have spent some time reading further on how the concept of modifiers could be realized and most approaches I have found seem to suggest the use of wrapper ops plus some syntactic sugar for modifiers wrapping a single operation.

It's also apparent from the literature that the possibility of applying a modifier to a group of quantum operations is essential to many concepts and optimizations. This might also influence the decision on #1110. Modifiers should be applicable to quantum-only regions.

It also brings up a further question: Right now, we handle controls as part of the operations themselves. This does not allow us to add controls to quantum-only regions yet. So it would be worth considering whether we also want to represent controls as explicit modifiers instead of them being part of the operation.

Last but not least, we should evaluate whether it is feasible to also allow modifiers as attributes on the operations in case they are statically known. This could potentially allow for more optimizations, but makes the optimizations themselves more complex. We can already see this in how we handle static and dynamic parameters.

[DRovara]

If we implement the "compound operation region" (#1110) as a concrete implementation of the UnitaryInterface (which intuitively makes sense, as a group of unitaries is also a unitary), then we can also incorporate the syntax and general approach for unitary gates there, including:

• controls using the ctrl/nctrl keywords
• pow/inv modifieres (once they are added to the UnitaryInterface)

This way, we would support a wrapper op and single-operation modifiers at once.

[burgholzer]

The only problem with that is that, at least in MQT Core, a compound operation is not necessarily unitary as it might contain Measurements, Resets, or classically-controlled operations.
And I think it would be beneficial to keep (or even extend) this flexibility of grouping.
However, maybe there are simply two levels of grouping:

• function-style grouping (using func.func or similar) that simply groups arbitrary operations
• pure-quantum grouping (with an Operation that implements the UnitaryInterface and has a block of operations that are part of the group)

Does that make sense?

[DRovara]

That distinction seems reasonable to me.
Of course this might raise the question why we don't just always use func.func and then just implement some inv/pow/ctrl wrappers for that, so we should be certain that this compound grouping really gives us some advantage, but generally it doesn't seem like a bad idea.