✨ Improve QIR support

[denialhaag]

#1710 has improved QIR support by providing separate conversions for the Base Profile and the Adaptive Profile.

This issue collects further improvements to our QIR support. It is expected to grow in the future.

• Extend the IR and pipeline test suites to cover the Base Profile.
• Use a centralized pass for converting a memref of qubits to a collection of static qubits, replacing the ConvertMemRefLoadOp pattern in the conversion to the Base Profile.
• Develop a verification tool to check profile compliance.

Please break out sub-issues as needed when implementing certain bullet points.

[burgholzer]

Use a centralized pass for converting a memref of qubits to a collection of static qubits, replacing the ConvertMemRefLoadOp pattern in the conversion to the Base Profile

@MatthiasReumann that's essentially an identity layout with all-to-all connectivity, right?
This sounds like something that could be split out of the place-and-route pass.

[burgholzer]

Develop a verification tool to check profile compliance.

Maybe we do not even need to develop this. There is the QIR Runner project (https://github.com/qir-alliance/qir-runner) which may be sufficient for us to test compliance.

[MatthiasReumann]

Use a centralized pass for converting a memref of qubits to a collection of static qubits

What is meant with "collection of static qubits"? An array as in Bullet 11 of the Adaptive Profile specification or simply N-many qco.static operations?

@MatthiasReumann that's essentially an identity layout with all-to-all connectivity, right? This sounds like something that could be split out of the place-and-route pass.

Last week @fiyoooo and me started to discuss how we could implement a PoC for NA routing in MLIR. Now, I am not an expert in NA quantum computing; however, although it has "all-to-all connectivity" it still requires shuttling, right? Should the transition from hardware-independent to hardware-aware qubits¹ - analogously to the existing superconducting mapping pass - then not also be done in a neutral-atom mapping pass? Wouldn't it be too simplistic to apply an identity layout?

Footnotes

1. I use this weird phrasing because I am not yet sure if the qco.static operations could / should also be used for NA (or Trapped Ion, or...) ↩

[burgholzer]

Use a centralized pass for converting a memref of qubits to a collection of static qubits

What is meant with "collection of static qubits"? An array as in Bullet 11 of the Adaptive Profile specification or simply N-many qco.static operations?

The latter is probably sufficient. The size of the memref needs to be known at compile time anyway for this to work. And at that point I currently see no direct benefit of an extra collection.

@MatthiasReumann that's essentially an identity layout with all-to-all connectivity, right? This sounds like something that could be split out of the place-and-route pass.

Last week @fiyoooo and me started to discuss how we could implement a PoC for NA routing in MLIR. Now, I am not an expert in NA quantum computing; however, although it has "all-to-all connectivity" it still requires shuttling, right? Should the transition from hardware-independent to hardware-aware qubits¹ - analogously to the existing superconducting mapping pass - then not also be done in a neutral-atom mapping pass? Wouldn't it be too simplistic to apply an identity layout?

Guess the answer here is, as most of the time, "it depends".
In principle, NA systems still a kind-of similar placement and routing pass that involves shuttling.
That would happen in a dedicated pass.
The comment above is rather for taking a generic circuit and converting it to the QIR base profile, which simply does not accept dynamic qubits, but otherwise has no connectivity constraints.

The HW modalities will likely use different operations and probably even qubit types as one probably wants to store coordinates for the atoms for example.

Footnotes

1. I use this weird phrasing because I am not yet sure if the qco.static operations could / should also be used for NA (or Trapped Ion, or...) ↩

[MatthiasReumann]

@burgholzer 👍🏻

The comment above is rather for taking a generic circuit and converting it to the QIR base profile, which simply does not accept dynamic qubits, but otherwise has no connectivity constraints.

Ah! Yeah, that makes sense 👍🏻

I guess, theoretically this could be done by the mapping pass. However, I'm not exactly sure how I would parameterize this 🧐. Something like --placement-only --trivial-layout seems kind of verbose to me. Maybe a standalone --apply-trivial-layout pass might not be that bad after all. Nonetheless, the respective pass must be able to deal with arbitrary sequences of allocations and deallocations (of qubits and tensors) eventually.

[burgholzer]

I guess, theoretically this could be done by the mapping pass. However, I'm not exactly sure how I would parameterize this 🧐. Something like --placement-only --trivial-layout seems kind of verbose to me. Maybe a standalone --apply-trivial-layout pass might not be that bad after all. Nonetheless, the respective pass must be able to deal with arbitrary sequences of allocations and deallocations (of qubits and tensors) eventually.

I would imagine something like --placement=trivial (in analogy to Qiskit's layout option) would be the best option here. Maybe combined with a --routing=none.