Conversation
…rite in the decomp-lowering pass
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3216 +/- ##
=======================================
Coverage 95.31% 95.31%
=======================================
Files 177 177
Lines 20861 20861
Branches 2103 2103
=======================================
Hits 19884 19884
Misses 771 771
Partials 206 206 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| return WalkResult::skip(); | ||
| } | ||
| if (isa<DecomposableGate>(op)) { | ||
| gateOutsideFunc = true; |
There was a problem hiding this comment.
Why would a gate ever appear outside a function?
| module.walk<WalkOrder::PreOrder>([&](Operation *op) { | ||
| if (auto func = dyn_cast<func::FuncOp>(op)) { |
There was a problem hiding this comment.
If you are just collecting all the functions I don't think you would even need a recursive call here, iterating over the module might be enough 🤔
| if (failed(runPipeline(ctrlPm, module))) { | ||
| return signalPassFailure(); | ||
| } | ||
| if (failed(lowerRoots(hasCtrlRegion, createCtrlLoweringPass))) { |
There was a problem hiding this comment.
Are we lowering adjoint/control after decomposing gates?
| size_t currentOpCount = countOps(); | ||
| if (currentOpCount == previousOpCount) { | ||
| break; | ||
| } |
There was a problem hiding this comment.
Identical op count is not a guarantee for identical IR 🤔 MLIR already implemented fixed point iteration in their greedy pattern applicator, maybe the instead of invoking nested passes here we should use that
2 participants
Context:
With the new changes to the graph-decomposition system, graph-decomposition applies the solver's chosen rules by iterating decompose-lowering, ctrl-lowering and adjoint-lowering to a fixpoint. Every pass in that loop ran over the whole module. Now that a program module carries the reachable rule closure alongside the QJIT-ed workflow, the rules dominate the module: in a one-gate test circuit (MyOp -> H, gate_set=["H"]) the module holds 125 func.funcs and ~3300 ops, of which the circuit is a handful.
decomp:lowering-fixpointwas 16.7 ms of a 19.2 ms decomp:total in PR #3206Description of the Change:
Adds
DecompUtils::getDecompositionRootsthat returns the circuits that the decompose-lowering should decompose/rewrite. Everyfunc.functhat is not itself a rule will fall back to the module itself when a module holds decomposable gates outside any function.Benefits:
Per-iteration cost is now proportional to the circuit rather than to the available rule set. On the test above:
before:
in this PR:
Possible Drawbacks:
Related GitHub Issues:
[sc-130390]