dialects: Add qref dialect

[alexarice]

Adds a qref dialect to xdsl, a variant of the qssa dialect which stores qubits as references rather than values.

@AntonLydike if you are interested

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.80%. Comparing base (0f6558a) to head (6358532).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2769      +/-   ##
==========================================
- Coverage   89.81%   89.80%   -0.01%     
==========================================
  Files         372      373       +1     
  Lines       47817    47884      +67     
  Branches     7331     7340       +9     
==========================================
+ Hits        42945    43004      +59     
- Misses       3736     3742       +6     
- Partials     1136     1138       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AntonLydike]

👍 Nice and simple, I like it!

I wonder if it'd be possible to generate the op definitions from some sort of spec in the future. How many different operations are there in quantum? is it just the handful of operations in this dialect, or are there tens or hundreds of them?

[alexarice]

I wonder if it'd be possible to generate the op definitions from some sort of spec in the future. How many different operations are there in quantum? is it just the handful of operations in this dialect, or are there a tens or hundreds of them?

I did wonder if it would be worth generating the operations in tandem, but @superlopuh advised against doing this.

There will likely be more operations than this, and I'm not certain on the best way to represent these yet (i.e. should they each be a separate operations or the same operation that refers to some symbol?)

I think this should be considered in the future but is likely not too relevant for this pr?

[n-io]

There will likely be more operations than this, and I'm not certain on the best way to represent these yet (i.e. should they each be a separate operations or the same operation that refers to some symbol?)

I think this should be considered in the future but is likely not too relevant for this pr?

It depends what and how much they share? The arith and csl dialects have plenty of 1-line ops with shared base classes. The idea is to have one class per emitted op.

[AntonLydike]

I think this should be considered in the future but is likely not too relevant for this pr?

💯 Absolutely! Just a random thought of mine!

[n-io]

Having had a very quick look, it appears that these might be the same ops as defined on qssa, but operating on different data types. Why have this as a separate dialect, rather than supporting e.g. an additional QRefAttr type on the ops?

[alexarice]

Having had a very quick look, it appears that these might be the same ops as defined on qssa, but operating on different data types. Why have this as a separate dialect, rather than supporting e.g. an additional QRefAttr type on the ops?

The (gate-like) operations in this dialect also have no results. In future a verify pass could(/should) be added to qssa to check that the qubits there are used linearly, but such a verification should not apply to this dialect.

[superlopuh]

I'm not sure how well the unification would work, and how much it might slow down making additions in the future. I think this is a great first thing to merge.

[n-io]

The (gate-like) operations in this dialect also have no results.

That's a good point. Shared semantics or not, the prospects of having the same 'if' in every method does indeed sound undesirable.

In future a verify pass could(/should) be added to qssa to check that the qubits there are used linearly, but such a verification should not apply to this dialect.

Is there any way the two flavours can co-exist in a manner not intended, and it leading to undesirable side-effects?

[alexarice]

Is there any way the two flavours can co-exist in a manner not intended, and it leading to undesirable side-effects?

Not with the current registered operations I believe