Add a few state-related cc ops

[annagrin]

Description

Add a few state-related cc ops:

• cc.create_state
• cc.get_number_of_qubits
• cc.get_state

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

This simplifies passes that seek to remove those ops, such as DeleteStates or ArgumentConversion.

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

[schweitzpgi]

This example only has 1 argument, but below it lists 2 arguments.

[annagrin]

forgot to update, thanks!

[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.

[schweitzpgi]

The type on this example doesn't correspond to the assembly below.

[annagrin]

forgot to update, thanks!

[schweitzpgi]

This should probably take a !cc.ptr<?> argument and make use of the cc.literal_string operation. That would be more flexible in the long run.

[annagrin]

sounds good, will do

[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.)