Remove the hardcoded list of runtime operations in the frontend #2215
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2215 +/- ##
===========================================
+ Coverage 78.94% 97.57% +18.62%
===========================================
Files 91 93 +2
Lines 10812 11254 +442
Branches 1064 1078 +14
===========================================
+ Hits 8536 10981 +2445
+ Misses 1919 208 -1711
+ Partials 357 65 -292 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| return True | ||
|
|
||
| # Accepted hyperparameters for quantum instructions bind calls | ||
| _accepted_hyperparams = { |
There was a problem hiding this comment.
@albi3ro Here's the minimum set of hyperparams that we always need to check for compatibility with the quantum.custom MLIR Op.
dime10
left a comment
dime10
left a comment
There was a problem hiding this comment.
Thanks Ali! Main concern is that the criteria is fairly loose compared to before. We should consider two factors in terms of validation:
- whether a custom operation is supported by the runtime c-api (a fixed set of linkable functions)
- This PR doesn't actually remove the underlying limitation, so by itself removing the check doesn't seem like an improvement. Are you planning on removing the underlying limitation in an immediate follow-up?
- whether any operation is supported by the compiler
- Generally this is a fixed set (all ops defined in the quantum dialect), plus any afforded by an extensibility mechanism (in this case only quantum.custom).
- Does the implemented verification match these restrictions exactly? In the current state I don't think so.
| return op.name in capabilities.operations | ||
|
|
||
|
|
||
| def is_lowering_compatible(op: Operator) -> bool: |
There was a problem hiding this comment.
I'm not convinced this function is sufficient to guarantee compatibility with the quantum dialect. Looking at the structure of an operator:
Operators are uniquely defined by their name, the wires they act on, their (trainable) parameters,
and their (non-trainable) hyperparameters. The trainable parameters can be tensors of any
supported auto-differentiation framework.
Name and wires are always supported by quantum.custom.
Hyperparameters are being checked below, although I don't know if the check is not too generic (i.e. I don't know if all hyperparameters are supported by all operation types).
The thing that's missing entirely is verifying parameters. Pennylane only requires that they be tensor-like, so this could be an arbitrary sequence of arbitrary tensors. This cannot be mapped to the quantum dialect at the moment. Some special ops support certain tensors (like 2D complex for quantum.unitary), but for the generic quantum.custom we would only support a sequence of scalar floats (or perhaps a single tensor that is flattened into a sequence of floats, but this could get highly inefficient if the tensor is large).
| return op.name in capabilities.operations | ||
|
|
||
|
|
||
| def is_lowering_compatible(op: Operator) -> bool: |
There was a problem hiding this comment.
Do we need to consider operations like quantum.measure at all, since its signature even has a return value 🤔
| "work_wires", | ||
| "work_wire_type", |
There was a problem hiding this comment.
Do we handle work wires when mapping to mlir?
| } | ||
| # A list of custom operations supported by the Catalyst compiler. | ||
| # This is useful especially for testing a device with custom operations. | ||
| CUSTOM_OPERATIONS = {} |
There was a problem hiding this comment.
Is there a point to keep this empty set, considering its entire purpose is to be unioned with something else?
Or is it just for tests? In that case possibly related: #2114
| a: Dict[str, OperatorProperties], b: Dict[str, OperatorProperties] | ||
| ) -> Dict[str, OperatorProperties]: | ||
| """Union of two sets of operator properties""" | ||
| return {**a, **b} |
There was a problem hiding this comment.
Any reason why not just
>>> x
{1: 2}
>>> y
{3: 4}
>>> x.update(y)
>>> x
{1: 2, 3: 4}
?
Context:
The frontend no longer maintains a hardcoded list of runtime operations, allowing arbitrary PennyLane gates with Quantum dialect-compatible hyperparameters to be captured and represented in MLIR. Users of the legacy compilation pipeline are unaffected, as Catalyst continues to decompose unsupported gates based on device capabilities before lowering to MLIR. Gates that cannot be represented as MLIR operators will temporarily raise a
CompileErrorduring program capture. The long-term solution will integrate the new decomposition framework with capture-enabled compilation.Description of the Change:
RUNTIME_OPERATIONSfromqjit_device.pyis_lowering_compatibleto check if an operation can be lowered to MLIR using primitives.from_plxprBenefits:
quantum.customophyperparametersat MLIRqml.transforms.decomposefor gates w/o runtime support, or just rely on the device decomposition to deal with unsupported opsPossible Drawbacks:
Related GitHub Issues:
[sc-102160]