🧊 MLIR - Eliminate qubit registers in MQTOpt (value semantics only)

[burgholzer]

Background

Registers make liveness/hoisting/reuse analysis harder and introduce boilerplate (alloc → extract → use → insert → dealloc).

Problem

Analyses must reason through register indirections and partial reuse, increasing complexity and risk of missed optimizations.

Proposal:

• In MQTOpt, allocate individual qubits and deallocate when done; convert from MQTRef register form during lowering to Opt.
• Update passes to operate on individual qubit values.

Acceptance criteria:

• Conversion implemented; passes adjusted; tests show simpler IR and correct behavior.
• Measurement hoisting and qubit reuse analyses become simpler/clearer (tests or before/after diffs).

[DRovara]

Just to list some more reasons why qubit registers are not that great:

• Let's not reinvent the wheel: List-/Array-like data structures in MLIR are limited, but they do exist.
• Obfuscation is part of the default pipeline: As soon as an extract/insert operation is called with a dynamic operand, reasoning statically what qubit is where becomes almost impossible. By requiring extract/insert operations for all qubit uses, we provide a very large "attack vector" for this problem.
• What's the canonical representation? Should each qubit use always be sandwiched between an extract and an insert or should extract/insert operations only be present at the start and end of the program. In either of these cases the qubit registers become quite useless anyways.

---

However, this change also adds a new challenge:
How do we translate from MQTRef to MQTOpt if MQTRef still uses registers? At the very least, this seems to be non-trivial, if not actually quite challenging.
Maybe the removal of qubit registers in MQTOpt also requires them to be removed from MQTRef (to be fair, most points above do not exclusively apply to MQTOpt. (See #1126)

[burgholzer]

I don't quite see the notion of registers going away in MQTRef. Basically every single language that currently comes to mind as an option for the input language has the concept of registers.
I would also argue that this is not just out of nothing. These notions seem generally useful in those languages.