Closed ausbin closed 2 years ago
Hey @ausbin this is not expected behavior. Basically we aren't letting staq translate the program to native U and CX gates, the CZ is sticking around, and then the visitor doesn't pick it up. I'll work on a fix.
I think I'm going to have to write a custom staq AST visitor for this I think. In the meantime you can just use the following replacement
__qpu__ void MyCZ(qubit q, qubit r) {
H(r);
X::ctrl(q,r);
H(r);
}
__qpu__ void kaboom(qreg q) {
X(q[0]);
H(q[2]);
MyCZ(q[0], q[2]);
H(q[2]);
Measure(q);
}
If you compile this with -opt 1 you'll get rid of the Hadamards.
Nevermind, don't need a visitor, the staq Inliner takes extra config parameters that can fix it. Got a fix coming into XACC for this.
fixed with xacc f1eedf04176b68241f6dc7dddaa5ae7453662da9
As far as I can tell, the
SwapShort
, aka"swap-shortest-path"
, IRTransformation considers only CNOTs and not other 2-qubit gates such as CZ. Please see the examplecz_repro.cpp
below:The CZ there is operating on qubits 0 and 2, which I chose because they are not directly connected in the coupling graph of the IBM backend I am targetting:
If you run this, IBMAccelerator correctly notices that the program has a 2-qubit gate on non-adjacent qubits:
If we change that kernel to this instead,
swap-shortest-path
correctly swaps qubits as needed, and it runs successfully:My guess is this is because the visitor inside staq itself is looking only for CNOTs and simply ignores the CZ:
https://github.com/eclipse/xacc/blob/f83e1825735c937686c4c04ba71ea37fbdd42b51/tpls/staq/include/mapping/mapping/swap.hpp#L84
Is this expected behavior? If not, how would this be fixed? Decompose two-qubit gates before they reach
swap-shortest-path
, or make it aware of other two-qubit gates, or something else? (I don't know which is why I'm opening this)