📐 MLIR - Optionally represent angles as fixed-point (quantized) type

[burgholzer]

Background

OpenQASM 3 provides a dedicated angle type that corresponds to binary angular measure (fixed precision). Some hardware only supports limited precision (e.g., a few bits) rotation angles.

Problem

Input programs (e.g. written in OpenQASM 3) might be using this angle type and we should be able to handle them.
Furthermore, some devices may only support limited precision for rotation angles.
Thus, we would need a quantization pass for rotation angles so that the resulting circuit can actually be executed on the hardware.

Proposal:

• Evaluate MLIR’s quant/fixed-point facilities to model angles; define a mapping and conversions to/from arith when needed.
• Decide where angle typing lives (Ref vs Opt vs frontend-only) and document trade-offs.

This partially depends on #30 if we want to build the support for the angle type into the regular MQT Core IR.
Alternatively, one could consider adapting the existing OQ3 parser to act as a direct translator to MLIR. There is no current tracking issue for that.

Acceptance criteria:

• Design note with chosen representation and examples; parser/lowering hooks planned or implemented.

[DRovara]

It does not seem unreasonable to me to use some fixed-point decimal type as the default data type for angles (replacing f64) rather than just supporting it optionally, for the reasons mentioned above.

Generally, it seems to be typical for MLIR to just support specific types and then require explicit conversions if the input includes a different type (e.g. scf.for requires the datatype index for the iteration limits - even if an existing variable of type i64 might be functionally equivalent, an explicit conversion is still required).

Maybe similar problems exist in other dialects, some research on that might be valuable.

[burgholzer]

It does not seem unreasonable to me to use some fixed-point decimal type as the default data type for angles (replacing f64) rather than just supporting it optionally, for the reasons mentioned above.

Hm. I am not yet 100% sure about that. In the scf example, that conversion is (mostly) lossless, while in the case of the angle type, I am not so sure whether this is always the case. It's also not quite clear to me, where the conversion would take place.
As stated in the OQ3 spec, the main purpose for the angle type is the limited availability of floating-point operations on the classical co-processors of QPUs. Thus, all computations involving the angles as part of the computation would already have to be performed on the angle type (not only the final conversion before plugging the angle into the parameter of a gate).
But given how MLIR does seem to support quantization, there must also be examples of other fields using that feature and I would hope that we can draw some inspiration from that.

This will definitely become relevant once we talk about hardware-near dialects, where quantization might be a requirement.