[MLIR] Translation between reference and value semantics

[ystade]

Within our work on MLIR, we have a dialect following value semantics used for optimisation(MQTOpt). Additionally, we have currently one dialect following reference semantics for easier translation between in-/output dialects (MQTDyn). Naturally, we need to convert between those two.

During conversion, one major issue are functions but also if-branches and while-loops consuming qubits. Such that the program is valid in value semantics all of them must return the new qubit value. However, that’s not needed in reference semantics. We now decided that the canonical form in reference semantics actually is that qubit references that enter a function are never returned.
In any case, we must modify function signatures during translation between those two dialects. Even though this does not seem intuitive for us, it was the only “correct” way we could think of.

Let’s have a discussion on that solution and other aspects that come up related to that conversion.

[erick-xanadu]

@ystade 🤔

We now decided that the canonical form in reference semantics actually is that qubit references that enter a function are never returned.

Do you mean here qubit registers references?

[erick-xanadu]

Yes, I think it makes sense that the signatures and return values will need to be changed. I do think it makes sense though. I would recommend that for the value semantics dialect one passes the register as input and returns it as output. I agree that it would be needed for control flow as well.

[DRovara]

I think this is the main slide related to that topic. (All pseudo-code representation for MLIR) On the left we have the reference-semantics way to represent some function and a call to it. On the right we have two alternative approaches to translate it to value semantics. Our first internal discussions resulted in choosing the first option.

[erick-xanadu]

Don't you also need to pass the register in the option below?

I think the first option makes a lot of sense. It would enable one to know which qubits are modified at the call site.

I think the option below does have at least one advantage. That is the calling convention is fairly easy, just pass the register as the first parameter and return the register as the first value. It also enables one to change the body of the function independent of the qubits. I.e., one could rewrite the function to reuse less qubits.

But one could always convert one from the other by hoisting the extract into the callsite.

[erick-xanadu]

These type of decisions are just design decisions :) I don't think there's a wrong one or a correct one.

[DRovara]

Don't you also need to pass the register in the option below?

Good point, I don't think we even considered that - so we would always have to modify the signatures.
But to be fair, as you say, at least it would be simple a simple transformation that can always follow the same calling convention.