🔁 MLIR - pow(r) modifier (integer r first; floats deferred)

[burgholzer]

Background

OpenQASM 3 allows pow(r) @ g where r is integer or float. The OQ3 parser in MQT Core recognizes pow but doesn’t lower it to operations. Qiskit offers a reference implementation pattern for powering gates with simplifications.

Problem

Introduce MLIR support for gate powering with a clear initial target (integer r) and a path for future floating-point r (principal logarithm of unitary), plus importer support from OQ3.

Proposal:

• Scope v1 to integer r:
  • r > 0: repeat g r times or apply gate-specific simplifications (e.g., pow(2) @ s = z; scale angles for phase families).
  • r = 0: replace with no-op (identity) where legal.
  • r < 0: rewrite to inv @ pow(-r) @ g.
• Represent as:
  • Attribute on op: {pow = r} with canonicalization to repeated/simplified gates; or
  • Wrapper op mqtref.power(%r) { ... } for region-level application, if needed.
• Defer float r: document that floating exponents require the principal logarithm of the unitary; keep as a TODO with clear error/diagnostic if encountered.
• Importer: translate OQ3 pow(r) @ g to the MLIR representation; for integers, perform eager canonicalization where obvious.

Depending on how #1130 turns out to be implemented, the implementation strategy here might be adapted.

Examples:

// Integer r > 0 (conceptual; to be canonicalized)
%q = ... : !mqtref.qubit
mqtref.rz %q, %theta {pow = 3} : (!mqtref.qubit, f64) -> ()
// Canonicalization: either repeat 3x Rz or compute equivalent parameter

// Negative r
// pow(-k) @ g  ==>  inv @ pow(k) @ g

Acceptance criteria:

• Integer r powering supported with verifier and canonicalizations (repeat or simplify).
• Importer handles OQ3 pow(r) (integers) and rejects/defer floats with a clear diagnostic.
• Tests for powering on standard gates (incl. simplifications); docs updated with examples and limitations.

[DRovara]

I'm not sure if it works to only support the pow(r) value as an attribute. In many cases, the power depends on some dynamically calculated value (e.g. in iterative QPE). In that case, the power would have to be an operand.

Only allowing that in the pow region but not the pow modifier also does not seem intuitive, as these two versions should probably be interoperable for transformations.

Maybe we should support static and dynamic pow modifiers?

[burgholzer]

As indicated in the top-level issue, I agree that only supporting the attribute version is probably not sufficient in general.
We should rather aim to support at least a wrapper op that may also wrap regions of quantum operations. Additionally, we might want to support a static variant.

[burgholzer]

The most recent design for the pow modifier can be found in the Dialect Design RFC in #1225

[J4MMlE]

Hey 👋 I'd be happy to work on this!