Not respecting target gateset?

[bachase]

I was inspecting the results of the default voqc compilation by setting

popqc/src/main.rs

Line 13 in 53909f7

const DUMP: bool = false;

to true, and then running cargo run configs/POAC_400/n64.toml. Looking at say the resulting benchmarks/grover_n9_from_python.qasm.eval file, I see the mix of gates below, which includes t,tdg,s. I was expecting the NAM target to only be rx,x,h,cx (as in the qiskit runner).

Is there a different definition for NAM gates that is being used?

# start of benchmarks/grover_n9_from_python.qasm.eval
OPENQASM 2.0;
include "qelib1.inc";
qreg q[9];
h q[0];
h q[1];
h q[2];
cx q[1], q[2];
tdg q[2];
cx q[0], q[2];
t q[2];
cx q[1], q[2];
t q[1];
tdg q[2];
cx q[0], q[2];
cx q[0], q[1];
t q[0];
tdg q[1];
cx q[0], q[1];
h q[0];
h q[1];
t q[2];
h q[2];
h q[7];
cx q[7], q[8];
tdg q[8];
cx q[4], q[8];
tdg q[8];
cx q[7], q[8];
rz(3.926991) q[7];
s q[8];
...

[liupengy19]

Thanks for catching this bug. I think t and s are just special cases of rz gates. So it shouldn't affect the total gate count. But I will investigate this later to make the output strictly follows the Nam gateset.