Challenges of bidirectional cirq <-> bloqade transpilation: `squin.cirq.emit_circuit`.

[jon-wurtz]

This is a blocker for QuEraComputing/bloqade#260.

Challenges with input and output values

circuit:cirq.Circuit = ...
kernel = squin.cirq.load_circuit(circuit,
                                 kernel_name="test",
                                 register_as_argument=False,
                                 return_register=True)

circuit2:cirq.Circuit = squin.cirq.emit_circuit(kernel)

which creates the qubits as part of the kernel and returns the qubits at the end-- aka, state prep. This throws an error EmitError: The method you are trying to convert to a circuit has a return value, but returning from a circuit is not supported.. Could any returns just be ignored?

Likewise,

circuit:cirq.Circuit = ...
kernel = squin.cirq.load_circuit(circuit,
                                 kernel_name="test",
                                 register_as_argument=True,
                                 return_register=False)

circuit2:cirq.Circuit = squin.cirq.emit_circuit(kernel)

Which inputs qubits from elsewhere and returns nothing at the end-- aka, an operator. This throws an error InterpreterError: SSAValue <BlockArgument[IList[Qubit, AnyType()]] q, uses: 15> not found which perhaps is reasonable (where are the qubits defined??) but nonetheless a bit unclear as an error message.

circuit:cirq.Circuit = ...
kernel = squin.cirq.load_circuit(circuit,
                                 kernel_name="test",
                                 register_as_argument=False,
                                 return_register=False)

circuit2:cirq.Circuit = squin.cirq.emit_circuit(kernel)

This does work, though that kernel functionally does nothing: it does state prep on some register, and then throws those registers away by forcing them to stay within its own scope.

Proposed simple solution: ignore any return values when transpiling back to cirq.

Challenges with conditional control

reg = cirq.LineQubit.range(8)
circuit = cirq.Circuit()
circuit.append(cirq.measure(reg[0], key="m"))
circuit.append(cirq.H(reg[1]).with_classical_controls("m"))

kernel = squin.cirq.load_circuit(circuit,
                                 kernel_name="test")
circuit2 = squin.cirq.emit_circuit(kernel)
kernel.print()

The forward works fine, but the reverse errors with the printed message else region must have a single block

[david-pl]

This is a blocker for QuEraComputing/bloqade#260.

What exactly are you trying to achieve here? What use-cases are we blocking? Could you give some more details here? The issue is pretty broad as it is.

Generally, I think this just raises the question: what should a squin kernel that is the equivalent of a cirq circuit look like in terms of function arguments and return values?

However, also keep in mind that we don't know where a squin kernel function comes from. So, when emitting a circuit from it, we also have to handle cases where the user wrote a kernel function.

1. I'd argue that just ignoring the return value can also be rather surprising for the user. That said, I'd be open to reduce it to a warning instead of an error. Still, what exactly are you trying to do here?

2. Similarly, it's not valid to pass in arguments to a circuit, but I agree that the error message could be clearer. We probably just need a validation of the circuit before trying to run the emit.

3. This one is quite tricky: generally, emitting a circuit from a kernel with control flow is just not supported right now. We discussed this recently, and intentionally left this out as it would add quite a lot of complexity. Sure, the case you have might seem simple, but dealing with if statements in general is tricky and we can never support everything.
   Some of the concerns with if statements are:

   • We'd need to validate the condition of the statement that it is based off a measurement. Any other condition should error.
   • Boolean operations on the conditions need to be considered and lowered accordingly.
   • Which statements are allowed inside the block?
   • Should the result be a set of classically controlled gates or a single sub-circuit with a classical control?

FWIW, you can work around these issues (for now) with something like this:

kernel = squin.cirq.load_circuit(circuit,
                                 register_as_argument=True,
                                 return_register=True)

@squin.kernel
def main():
    q = squin.qubit.new(2)
    result = kernel(q)
    return None

circuit_out = squin.cirq.emit_circuit(main)

This is not very nice from a UX point of view and also will result in a bit of an odd circuit which contains a sub-circuit that is basically the entire original circuit. But at least it works.

[jon-wurtz]

This is a blocker for #260 in that the complete tutorial should also be able to cleanly explain this bidirectional cirq. It's not a strict blocker 👼.

We can have a collection of wrappers like what you described, which wrap a kernel (that takes IO) into something that doesn't take IO as needed; for example,

def wap_kernel(kernel:kirin.types.Method, nqubits:int)-> kirin.types.Method:
    @squin.kernel
    def main()-> list[bool]:
        q = squin.qubit.new(nqubits)
        r = kernel(q)  # Apply the kernel to the register.
        bits = squin.qubit.measure(r)
        return bits
    return main

would be a "full" wrapper around a kernel, and we could have methods that, for example, prepare qubits but don't return anything, return qubits but don't take anything in, and so forth. I already have a few of these in the tutorials.

The inputs might be able to be bypassed by matching the signature of the function to the emit; for example,

@squin.kernel
def main(qubits:IList[Qubits], i:int, var:float):
   ...
squin.cirq.emit_circuit( main, {"qubits":cirq.LineQubit.range(4), "i":5, "var":0.123} )

Though throwing an error if there are variable inputs would be an easy out.

Outputs as a warning instead of an error might be better UX as well. Perhaps unexpected, but "user beware".

I agree that the reverse of kirin->cirq is generically quite nasty. There is some pretty heavy pattern matching that would have to occur to be able to reverse a kernel built out of cirq. Perhaps we can just make a better error message ("feed-forward control flow is not allowed") or similar.

[david-pl]

We can have a collection of wrappers like what you described ...

What would the workflow look like when using these?

@squin.kernel
def main(qubits:IList[Qubits], i:int, var:float):
   ...
squin.cirq.emit_circuit( main, {"qubits":cirq.LineQubit.range(4), "i":5, "var":0.123} )

This API seems a bit weird to me, since the type of the qubits argument doesn't match the function signature. There's an implicit conversion happening here.

Also, there's already the functionality to pass in qubits into the emit via

squin.cirq.emit_circuit(main, qubits=cirq.LineQubit.range(4))

Of course, this will still error since main requires arguments.

What you actually want is to call main inside another kernel providing the arguments and then inline that call:

@squin.kernel
def main(qubits:IList[Qubits], i:int, var:float):
   ...

@squin.kernel
def wrap_main():
    main(squin.qubit.new(4), 5, 0.123)


from kirin.passes import inline
inline.InlinePass(main.dialects)(wrap_main)
squin.cirq.emit_circuit(wrap_main, qubits=cirq.LineQubit.range(4))

I'm not sure what a good UX for doing this "automatically" is.

[david-pl]

@jon-wurtz To summarize, I've created a number of sub-issues which should address each part of this issue. Let me know if I missed anything.