Change __global__ register bit ordering for target mode to match library mode

[bmhowe23]

Regarding #978, this change makes the __global__ register behave the same in target mode (both real backends and emulation) as library mode. To do this, the following changes were made:

• Mapping no longer requires measurement names and instead enforces that the post-pass measurement order is the same as the pre-pass measurement order.
• Removes CircuitSimulator logic that was synthesizing the __global__ register based on alphabetically named results, which means they are now in measurement order of the original program. Due to Fix library mode qubit ordering bug. #1044 they are now in qubit allocation order.
• If no measurements exist going into the mapping pass, add the implicit measurements to ensure that the final measurements match what would've happened if mapping had not been run.
• Update IonQ, OQC, and Quantinuum server helpers to match the library mode behavior.
• Remove the iqm_IQMTester.executeNoMeasurementsProgram test because it was expecting an exception to be thrown if there were no measurements in an IQM program, but since measurements were implicitly added by the mapping pass, this no longer occurs. (This matches the behavior in library mode, so I believe this is a good change.)
• Add test to check __global__ register in library mode vs non-library mode(s)
• Docs update to clarify bitstring ordering of __global__ register.

Note that this PR will not fully resolve the above issue because named registers still exist in the returned sample_result, and that issue correctly notes that those named registers are not currently present in library mode.

Potential items for further discussion

• The delay-measurements pass can change whether or not the final operation is a measurement. This, in turn, can affect how the global register is formed. There is a commented-out test that demonstrates this behavior.
• As part of this testing, I realized that the Quantinuum backend seems to hang if you do any programs that don't have any measurements in them. We probably need to open a new issue for that.

Detailed implementation notes

• Library mode sampling introduces implicit measurements at the end of the program if there were no explicit measurements UNLESS cudaq::observe is being called. If cudaq::observe is being called, the measurements are injected in the ObserveAnsatz pass.
• The mapping pass can introduce additional qubits. In order to match library mode behavior, these qubits should not be measured and reported back to the user.
• In order to keep track which qubits should be measured and reported back to the user, the mapping pass now first inspects if the kernel contains any measurements. If it contains measurements, the order of those measurements is retained. This is critical to keeping the measurement interpretation of unnamed measurements the same pre-mapping vs post-mapping. If the kernel contained no measurements, the mapping pass injects them. This is required to help the runtime track which qubits and measurements are supposed to be reported back to the user.
• Now, the ObserveAnsatz pass may receive see a kernel with measurements introduced by the mapping pass. For observe, it is critical that not all qubits are measured and reported back to the user, so we have to REMOVE the measurements that mapping added and add only the ones that are desired for observe.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[amccaskey]

Thanks for looking into this Ben. I appreciate the added test and the docs update, they were very helpful.

My one question - why order the global register by the order of the measurements? The original thought behind the global register was that it would represent the final classical state of user-specified measured qubits (or all if none provided). The ordering was meant to be the same ordering as the qubits (vector-like ordering). One concern I would have is that the two equivalent circuits you demonstrate in the docs update produce two different results and this may be a point of confusion later on (despite the well-laid out explanation in the docs). Let me know if I'm missing something or likely there was a bug in the initial implementation.

[bmhowe23]

My one question - why order the global register by the order of the measurements?

I didn't change the behavior of the global register in library mode in this PR ... I just documented the behavior and made non-library mode match it. If you're saying that the currently library mode ordering is a bug, then we should probably open a new issue and decide what to do about the docs updates in this PR. They were intended capture the current state of the code, but if we anticipate changing that, then we need to decide whether or not we would a) publish/push the additional docs in this PR to describe the current state and just update the docs if/when we change the behavior in the future, or b) remove the docs update from this PR and capture them separately after any potential ordering changes are made. I'm open to either of those options (or any additional options, too), but I tend to favor (a) since it documents the current behavior.

[amccaskey]

Awesome, this is what I was sort of starting to think. I'm a proponent of fixing the bug in CircuitSimulator and ensuring that the ordering corresponds to the ordering of the allocated qubits. It might also be good in a future patch to explicitly store the qubit to bit mapping in sample_result.

[bmhowe23]

I'm a proponent of fixing the bug in CircuitSimulator and ensuring that the ordering corresponds to the ordering of the allocated qubits.

OK, it sounds like I should move this PR back to "draft" and open a new PR to make library mode perform as you describe first. It may require some rework on this PR because this PR is ordering things based off of QIR result number in the backends, so we may need to change it to be based off of QIR qubit number if we make the change to CircuitSimulator.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[1tnguyen]

LGTM 👍

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.