Add a few state-related cc ops

[annagrin]

Description

Add a few state-related quake ops:

• quake.create_state
• quake.delete_state
• quake.get_number_of_qubits
• quake.get_state

The ops are created by the kernel builder or the AST bridge and are either optimized away during argument synthesis, or converted to MLIR in QuakeToCodegen pass.

This simplifies passes that intend to remove those ops, such as DeleteStates , ArgumentConversion, or ReplaceStateWithKernel (to be added in the dependent PR below)

Note: this is also a prerequisite for creating a simpler quantum state synthesis passes: #2291

[schweitzpgi]

I'm thinking we should put these in the quake dialect.

First, these really correspond to quantum operations in the end. As such they are successively lowered to (recursive?) kernel application or high-level abstract calls to a quantum simulator/emulator.

Second, they just don't have a classical computation semantics (see issue 1). In that context, they really aren't anything the compiler can reason about in terms of classical computation and behave as opaque calls to unknown external code.

[boschmitt]

I'm thinking we should put these in the quake dialect.

+1

I wonder with the cc.state type shouldn't also be moved to quake. Although it is a vector (array) of complex values, the moment we attach this specific interpretation for it, it jumps the fence to the quake side of things. (If we had left those as raw vector/array, then this interpretation would be given by the op that takes it, i.e., we would only know that a vector/array corresponds to a state if a quake.init_state use it as input.)

[annagrin]

I wonder with the cc.state type shouldn't also be moved to quake. Although it is a vector (array) of complex values, the moment we attach this specific interpretation for it, it jumps the fence to the quake side of things. (If we had left those as raw vector/array, then this interpretation would be given by the op that takes it, i.e., we would only know that a vector/array corresponds to a state if a quake.init_state use it as input.)

That sounds reasonable to me, but I would like to address it in a separate PR, to keep changes smaller.

[schweitzpgi]

I wonder with the cc.state type shouldn't also be moved to quake. Although it is a vector (array) of complex values, the moment we attach this specific interpretation for it, it jumps the fence to the quake side of things. (If we had left those as raw vector/array, then this interpretation would be given by the op that takes it, i.e., we would only know that a vector/array corresponds to a state if a quake.init_state use it as input.)

That sounds reasonable to me, but I would like to address it in a separate PR, to keep changes smaller.

I agree. It's morphed its way from being just a vector of complex (as in exactly the CC type) to its own distinct type that only makes sense when used in a quantum context. I think moving it to quake will eliminate some cross-dependencies that have crept in as well.