QASM3: Compiler conformance

[1tnguyen]

1. We're unable to compile the IQPE example from the OpenQASM3 paper.

Looks like we lack the support for the angle type and pow(2**i) (variable/not constant in the pow modifier)

/*
 * Iterative phase estimation
 */
OPENQASM 3;
include "stdgates.inc";
const n = 3; // number of iterations 
const theta = 3*pi/8; //phase angle on target qubit
qubit q; // phase estimation qubit
qubit r; // target qubit for the controlled-unitary gate 
angle[n] c = 0; 
// initialize
reset q;
reset r;
// prepare uniform superposition of eigenvectors of phase
h r;
// iterative phase estimation loop
for i in [1:n] { 
  reset q;
  h q;
  ctrl @ pow(2**i) @ phase(theta) q, r;
  inv @ phase(pi) q;
  h q;
  measure q -> c[i];
  // newest measurement outcome is associated to
  // in the next iteration, so shift all bits of c left 
  c <<= 1;
}

2. The quantumDeclaration syntax is updated:

/** Quantum Types **/
 quantumDeclaration
     : 'qreg' Identifier designator? | 'qubit' designator? Identifier
;

i.e. a qubit array is now declared as qubit[20] qubit_array; vs. the old syntax qubit qubit_array[20];

[moar55]

I can take on this issue. There are a couple of changes in the latest OPENQASM3 grammar. Which will need to be reflected in the OPENQASM3 visitor.

[moar55]

Would it be wise to do all new grammar conformance changes first then create a pull request? I just feel that it would be too much code to merge at once...

[amccaskey]

I'd prefer to break it up into smaller PRs for each conformance change.

[moar55]

Sounds good

[moar55]

In the latest grammar the power operator is denoted by **. While the xor operator is denoted by ^ , and the semantics specify that it is reserved for bit types only. In the current implementation ^ is used as the power operator and I couldn't find an implementation for the xor operation. I know we want to avoid backwards incompatibility, but I think sticking to the openqasm spec in this one would prevent confusion and would be handled more elegantly in the code. What do you think?

[amccaskey]

Yea this would be a case where I’d say we should update our impl to adhere to the spec and not worry about backwards compatibility. Feel free to tackle that! 😀

[adinwritescode]

Hi,

May I ask if this issue was ever fully addressed? At least in the Docker build, a similar error is thrown for declaring a classical bit array, making me suspect that an outdated grammar is still being used.

Source:

OPENQASM 3;
include "stdgates.inc";
bit[5] meas;

When trying to emit MLIR:

[OPENQASM3 MLIRGen] cannot parse the source.
error: no viable alternative at input 'bit[5]meas'
occurred at demo:3:7, offending symbol = meas

Thanks