-
Notifications
You must be signed in to change notification settings - Fork 57
Add support of MCM for decompose pass and some refactoring #2068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Hello. You may have forgotten to update the changelog!
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2068 +/- ##
=======================================
Coverage 97.48% 97.48%
=======================================
Files 91 91
Lines 10594 10594
Branches 990 990
=======================================
Hits 10328 10328
Misses 211 211
Partials 55 55 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
} | ||
qubit = customOp.getQubitOperands()[0]; | ||
} | ||
else if (auto measureOp = dyn_cast_or_null<quantum::MeasureOp>(qubit.getDefiningOp())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use interfaces whenever we can, which might save you from having to add all these instructions one by one :) Unfortunately, measure doesn't seem to implement any of our interfaces, but the CustomOp above may be better served with the QuantumOperation or QuantumGate interface.
Although I'm a little confused why we just get the 0th qubit operand, are we guaranteed to only deal with single-qubit operations here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, why not get the index and register together in one walk, rather than in separate functions? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, why not get the index and register together in one walk, rather than in separate functions?
Yes, I agreed, I updated this in another PR #2074, but it might take more time to handle that one, so I can move that change to this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although I'm a little confused why we just get the 0th qubit operand, are we guaranteed to only deal with single-qubit operations here?
It's because this function here is used to get the source qreg, at the point, only one qreg, the global one exists. So traverse different qubit operands would still reach the same qreg. But now we have dynamic qreg! So this method will need to be changed and follow the solution from #2074
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Context:
Description of the Change:
Added traversal logic of mcm. For an example, finding the
qreg
and index ofqb3
in the following case, it needs to traverse the def-use chain through the ops.Refactoring
QuantumGate
to traverse the gates instead ofCustomOp
Benefits:
Possible Drawbacks:
Related GitHub Issues:
[sc-100311]