Track graph operation IDs in decomposition resource analysis by sengthai · Pull Request #3102 · PennyLaneAI/catalyst

sengthai · 2026-08-05T20:49:23Z

Context:
Previously, ResourceAnalysis grouped quantum operations using only their name, wire(qubit) count, and parameter count, producing identifiers. Meanwhile graph-decompositions uses graphOpId, which also captures parameter types, wire structure, static data, and operator UIDs (some of these are part of Operator2).

This PR aligns resource generation with graphOpId by adding an optional detailed operation count used specifically by decomposition passes.

To use that, developer can toggle collectDetailedOperation when construct the analysis.

[sc-125008]

Co-authored-by: David Ittah <dime10@users.noreply.github.com>

Co-authored-by: Hong-Sheng Zheng <mathan0203@gmail.com>

This reverts commit f11271a.

sengthai · 2026-08-07T20:42:11Z

                collectOperation(&op, result, isAdjoint);
+                if (collectDetailedOperations) {
+                    collectDetailOperation(&op, result, isAdjoint);
+                }


In ADR, we stated the mechanism that allow us to toggle between quantum_operation and quantum_operation_detailed, but in actual implementation, we still need to perform for quantum_operation by the way, because it needs to collect the function name for handling function call. Also, since buildResourceDict() serializes only detailOperations into MLIR attribute, we here just toggle only quantum_operation_detailed.

If we needed to we could probably collect the function names using CollectDetailedOperation, but I think the current solution is fine, it shouldn't be much more expensive and saves us having 2 implementations.

jzaia18

Looks good so far, just a few comments

jzaia18 · 2026-08-10T20:03:34Z

                collectOperation(&op, result, isAdjoint);
+                if (collectDetailedOperations) {
+                    collectDetailOperation(&op, result, isAdjoint);
+                }


If we needed to we could probably collect the function names using CollectDetailedOperation, but I think the current solution is fine, it shouldn't be much more expensive and saves us having 2 implementations.

jzaia18 · 2026-08-10T20:10:40Z

 * @return DictionaryAttr representing the resource counts
 *
 */
 DictionaryAttr buildResourceDict(MLIRContext *ctx, const ResourceResult &result) {


Doesn't this method only work if we collect detailed operations now? What if the user didn't select this setting?

If the user didn't enable collectDetailedOperaitons here.

catalyst/mlir/lib/Catalyst/Transforms/RegisterDecompRuleResourcePass.cpp

Lines 39 to 40 in 0a277f1

ResourceAnalysis analysis(module, {}, /*collectDetailedOperations=*/true);

then, this return empty operations.

But that's a bug, isn't it? If we leave collectDetailedOperations as false then the output JSON will be completely missing all operations data

i can see that. Being empty when collectDetailedOperations is false seems incorrect interpretation. Okay, i will add an assert if in that function then.

jzaia18 · 2026-08-11T13:53:14Z

This seems like we're replacing the existing unit tests with ones that check the detailed ops. I think we should instead add new unit tests -- we still want to test that the old pathway works as well

what the old pathway you mention here? We actually replace the existing detailed ops fetching, completely.

jzaia18 · 2026-08-11T13:54:18Z

 // Rule with measure

-// CHECK: resources = {measurements = {}, num_alloc_qubits = 1 : i64, num_arg_qubits = 0 : i64, num_qubits = 1 : i64, operations = {"Hadamard(1,0)" = 1 : i64, "MidCircuitMeasure(1,0)" = 1 : i64}}, target_gate = "gate"
+// CHECK: resources = {measurements = {}, num_alloc_qubits = 1 : i64, num_arg_qubits = 0 : i64, num_qubits = 1 : i64, operations = {"Hadamard[][1]{}" = 1 : i64}}, target_gate = "gate"


Why do we no longer expect the MCM to show?

I include it in 0a277f1

Co-authored-by: Jake Zaia <23638795+jzaia18@users.noreply.github.com>

Fix missing adjoint in detailedOperaiton

jzaia18 · 2026-08-11T20:38:18Z

+        std::string opId = inst.getGraphOpId();
+        if (auto resourceOp = dyn_cast<ResourceQuantumOpInterface>(op)) {
+            if (isAdjoint ^ resourceOp.getResourceAdjointFlag()) {
+                opId += "[adj]";


Will this break anything for the actual decomposition graph IDs?

CC @kipawaa

FYI, it should be like Rot[f64,f64,f64][2]{}[adj]

jzaia18 · 2026-08-11T20:39:18Z

+            }
+        }
+        result.detailedOperations[opId] += 1;
    }


Don't forget to add an else-branch to catch cases when we don't have a graph operator ID

I added another if-branch for handling the ResourceAnlaysis op type. 0a277f1

I'm sure how we handle unknown quantum ops here. So, i would leave that alone for unknown op as it can be classical ops as well.

sengthai and others added 20 commits August 5, 2026 16:44

Support PBC ops' count

cd6761c

fix test frontend

c227ff4

Added resource extension

973a672

format code

c23235b

improve the doc

56c6098

implement CRTP on resource extension analysis

f9c1c26

Apply suggestions from code review

3e49946

Co-authored-by: David Ittah <dime10@users.noreply.github.com>

remove the cmakelist from PBC Analysis

59e1ddc

use 2 style slashes

302c7de

move MergeMethod to ResourceResult

f7d9c54

Skip and warn the dubplicated extension names

75d56e1

rename class name

00e7143

Update mlir/include/Catalyst/Analysis/ResourceAnalysisRegistry.h

95c441c

Co-authored-by: Hong-Sheng Zheng <mathan0203@gmail.com>

code format

e8d37b9

use RES_EXT_CONCAT

9d6ff11

Standalize JSON output

08e176c

Fix test file

55ea274

Improve PBCDepthExtension::toJson()

fd6b70f

Replace changelog reminder action with local git check

ef25e1e

Revert "Replace changelog reminder action with local git check"

01b81e5

This reverts commit f11271a.

sengthai changed the title ~~add graph op id~~ Add new field for quantum operation detailed in resource analysis for graph decomp Aug 5, 2026

sengthai added 8 commits August 5, 2026 17:03

revert

0f460f8

Record the quantum op in detail

45a7793

Merge branch 'ex-re/reshape-json' into add-graph-op-id

f28c3cd

code format

358710d

update mlir test

64a99be

Added collectDetailedOperation flag

d8fa320

Only show quantum_operations_detailed when it's non-empty

f3d4c9e

Merge branch 'ex-re/reshape-json' into add-graph-op-id

d52eeda

sengthai changed the title ~~Add new field for quantum operation detailed in resource analysis for graph decomp~~ Track graph operation IDs in decomposition resource analysis Aug 7, 2026

update changelog

632af26

sengthai marked this pull request as ready for review August 7, 2026 19:55

sengthai requested review from jzaia18 and kipawaa August 7, 2026 19:55

sengthai commented Aug 7, 2026

View reviewed changes

jzaia18 reviewed Aug 10, 2026

View reviewed changes

jzaia18 reviewed Aug 11, 2026

View reviewed changes

Comment thread mlir/test/Catalyst/RegisterDecompRuleResourceTest.mlir Outdated

jzaia18 reviewed Aug 11, 2026

View reviewed changes

Comment thread mlir/test/Catalyst/RegisterDecompRuleResourceTest.mlir Outdated

jzaia18 reviewed Aug 11, 2026

View reviewed changes

Comment thread mlir/test/Catalyst/RegisterDecompRuleResourceTest.mlir Outdated

sengthai and others added 3 commits August 11, 2026 10:30

Apply suggestions from code review

f137223

Co-authored-by: Jake Zaia <23638795+jzaia18@users.noreply.github.com>

Fix typo var name

d7682ba

Fix detailedOperation merge/multiply logic

4b092a7

Fix missing adjoint in detailedOperaiton

jzaia18 reviewed Aug 11, 2026

View reviewed changes

sengthai added 2 commits August 11, 2026 17:14

Added detailed operation function in Resource Analysis Interface

0a277f1

Add assert in buildResourceDict

fbea7aa

	ResourceAnalysis analysis(module, {}, /collectDetailedOperations=/true);

Uh oh!

Conversation

sengthai commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sengthai Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzaia18 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzaia18 Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jzaia18 Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sengthai commented Aug 5, 2026 •

edited

Loading

sengthai Aug 7, 2026 •

edited

Loading

jzaia18 Aug 10, 2026 •

edited

Loading

jzaia18 Aug 11, 2026 •

edited

Loading