jvansomeren
commented
1 year ago The reference updater include/ql/com/map/reference_updater.h and its source src/ql/com/map/reference_updater.cc update in an instruction (includes a gate) the qubit operand(s) from virtual to real, i.e. applies the qubit mapping, when the gate has just been mapped.
The code states that this assumes that the gates are in the generalized form (since virtual qubits are all equal, not hardware bound, and need not nearest-neighbor).
And after this reference updating, it turns the gate in its specialized form; this can be done since the qubits are real now.
But why is the gate brought in its specialized form during mapping? For one thing, it is the first opportunity to do this since the qubits just became real. It allows for different gate descriptions for virtual operands and for real operands. Perhaps gates, while being mapped, are automatically specialized, and is specialized just the gate form for real qubits; so generalized/specialized is coupled to virtual/real.
Without mapping, all qubits are NN, and all qubits are virtual AND real; then having the difference is not necessary; this would explain why both specialized and generalized are there: a choice could not be made. Without mapping, I see no reason for the generalized form when there is also a specialized form; so generalized without specialized is ok but with not. With mapping, it is also ok when there is no specialized form because then the generalized form applies to real qubits as well.
A gate may have values for an attribute that depend on the particular qubit index of an operand. The configuration specification supports specifying this, and thus at some time during compilation, one wants to specialize a gate application as far as possible to get the operand dependent attribute values. An example is the duration attribute of a gate. Currently in OpenQL, this is an action: to turn the gate application in its specialized form, or even back into its generalized form. What you would want is an interface that an attribute values retrieval would check operand index values to find the proper attribute value. I.e. we get rid of this state of being in specialized or generalized form. In OpenQL, qubit operands always have an index value, but in case that would not be so, then an undefined index value could lead to an undefined attribute value (or the largest of all, or the smallest of all but that requires too much specs). This would also simplify the IR: one step further into the direction that the acceptance of an IR to a pass doesn't depend on some state (another example is qubits being virtual or real).