taalexander
commented
2 years ago OpenQASM3.0 exposes structured control flow from a user-facing language perspective (for relatively sane reasons). There are no constraints on what representation the compiler uses to optimize and target the program to the hardware. I do suspect that structured control-flow is preferable from the perspective of hardware vendors in the current NISQ era, where most control systems are composed of many heterogeneous nodes with various responsibilities, and implementing such decisions across the distributed system while maintaining real-time deadlines for signal generation is a difficult problem. Generating target code for such systems is certainly simpler when arbitrary CFGs are not allowed.
However, given the above perspective, there is also the perspective of the language developer targeting OpenQASM3.0 who might reasonably desire to avoid the lossy conversion back to SCF through something like Relooper. Since OpenQASM in many ways has been used (and advertised) as a compilation target I think this topic should be carefully considered so as to potentially avoid making some of the perceived mistakes of WASM.
What is the expected behavior?
The majority of classical compilation breaks down control flow into the control flow graph and then captures this in the emitted assembly code by labels for basic blocks and branches or jumps to those labels to recreate the flow between blocks. As much as OpenQASM is not trying to provide for general-purpose classical computation, this would also be a convenient way to express the control flow at the low level, e.g. the physical OpenQASM circuit emitted by a compiler. Otherwise, the constraint of having to express the control flow in terms of conditionals and loops (the only control flow tools currently available in the spec) can make the job of a compiler much more difficult than necessary if it is to try and perform significant control flow optimisations.
It is totally possible to emulate any arbitrary control flow with a single loop and a lot of conditionals, so this doesn't strictly add flexibility, but depending on the way control flow is handled by the device this emulation could certainly come with some performance costs.
If labelled jumps were intentionally omitted for some design reason, we might benefit from a note of this in some extended documentation, since this would probably have impacts on the abstract machine OpenQASM presents to users, hardware supporters, and compiler developers.