⚡️ Evaluate JIT-backed execution for dynamic QCO programs

🤖 AI text below 🤖

Context

The QCO decision-diagram functionality added for #1915 interprets quantum and
classical MLIR operations directly. This gives the implementation control over
DD construction, supplied initial states, static sampling, allocation, and
deallocation, but it also requires explicit handling of operations from
arith, math, cf, scf, func, and memref.

MLIR provides an ExecutionEngine, but it does not execute arbitrary QC or QCO
operations directly. A module must first be lowered to LLVM-compatible
dialects. Quantum operations must become calls to registered runtime functions.
The existing DD-backed QIR runtime already provides a closely related execution
model.

Goal

Investigate whether genuinely dynamic QCO programs should be lowered and
executed through MLIR's JIT infrastructure and the existing QIR runtime instead
of extending the manual classical interpreter.

Proposed prototype

• Lower a representative dynamic program through QCO, QC, Adaptive QIR, and
  LLVM-compatible dialects.
• Execute the lowered module with mlir::ExecutionEngine or reuse the existing
  QIR runner infrastructure where practical.
• Register DD-backed implementations for the required quantum runtime calls.
• Compare semantics, implementation size, diagnostics, and performance with
  direct QCO interpretation.
• Determine whether static sampling can remain on the direct DD path while the
  JIT path handles measurement-dependent control flow.

Questions to resolve

• Can the existing QIR runtime be reused without duplicating execution state or
  runtime-call implementations?
• Which QCO allocation and deallocation semantics survive the current lowering
  pipeline?
• Which interfaces are required for caller-supplied initial DDs, symbolic
  argument bindings, and dynamic QTensor extents?
• Should matrix-DD construction remain exclusively on the direct path?
• Can density-matrix execution and partial trace be exposed through suitable
  runtime calls, or should they remain direct DD operations?
• How should the implementation select between static DD execution and dynamic
  JIT execution?

Expected outcome

Produce a small end-to-end prototype and an architecture decision. If the JIT
path is viable, split the required lowering and runtime interfaces into focused
implementation issues. Otherwise, document the blockers and retain the direct
interpreter with a clear supported-operation boundary.

References

• mlir::ExecutionEngine
• Toy tutorial: lowering to LLVM
• MLIR target LLVM IR
• QCO DD functionality stack: #1973, #2077, #2078, #2079, #2080

Start by reading the MLIR ExecutionEngine and the existing DD-backed QIR runner, then trace the QCO-to-LLVM-compatible lowering path through QCO, QC, and Adaptive QIR. Build a small end-to-end prototype for a representative dynamic program and compare it with direct QCO interpretation. Done means an architecture decision documenting viability, required runtime interfaces, or blockers and the supported-operation boundary.