-
Notifications
You must be signed in to change notification settings - Fork 57
🚧 A compiler native Decomposition Graph Solver in C++ #2065
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
Draft
maliasadi
wants to merge
52
commits into
main
Choose a base branch
from
gdecomp_solver_cpp
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…r e2e testing from v3)
… present in MLIR (#2001) **Context:** Introduces a new MLIR pass that enables user-defined decomposition of quantum gate operations. The pass discovers decomposition functions in the module and uses MLIR's inlining infrastructure to replace target quantum operations with their decomposed implementations. **Description of the Change:** This PR will **recognize** the `func.func` as decomposition if they have name start with the pattern `<Gate>_rule[.]*` where the `<Gate>` is a `quantum.custom` op it expect to replace (It's not what generated from frontend). Also you can just mark the attributes `catalyst.decomposition` and `catalyst.decomposition.target_op` at decomposition function, it still works. And this pass just **discover** those decomposition functions and **replace** the target operation with `call` to the function and rely on the Inliner interface to inline these decomposition function if needed. The stages of the `--decompose-lowering`: 1. `decompose_lowering.cpp`: Main pass that orchestrates the decomposition process 2. `DecomposeLoweringPatterns`: Pattern rewriting logic that replaces `quantum.custom` operations with function call 3. `QuantumInlinerInterface`: Dialect interface that enables MLIR's inliner to process quantum operations correctly 4. Remove unused decomposition function (if the inliner decide not to inline the certain function, then it will leave a `func.call`, so the func is used, shouldn't be removed) The type signature between decomposition function provided from the frontend is different to the `quantum.custom` op, `OpSignatureAnalyzer` does the trick to get the enough information to generate a function call to decomposition function. Current right now, frontend choose to generate the decomposition function with type: ``` (qreg, param*, inWires*, inCtrlWires*?, inCtrlValues*?) -> qreg ``` We need to figure out the information that need to pass to create the function call: qreg, `in wires indices`, and `in ctrl wires`. `OpSignatureAnalyzer` will use the target `quantum.custom` op (that one we need to replace) to traverse the qubit, and find out the qreg, and wire indices. The traversal logic based on the following assumption for the quantum dialect: 1. The ordering of qubits is preserved in quantum instructions 2. For other instructions, they will use a register, so will hit an extract before them It promise that every gates, the result (qubits) will match to the operands (qubits) at the same index. That's the important assumptions to support the traversal logic here. Traverse the qubit, match the index, keep going up until reach the `qauntum.extract` operation. After then, we use those information to generate a function call and rely on the Inliner in MLIR infra to replace it. **Benefits:** The decision to use MLIR's inlining infrastructure (`InlinerPass`) is to provide future-proofing and flexibility. **Possible Drawbacks:** **Related GitHub Issues:** [sc-98593] --------- Co-authored-by: Ali Asadi <[email protected]>
…talyst into feature/handle_gdecomp_v4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context:
Prototype PL's DecompositionGraph in C++ for integration with the Catalyst core compiler
Benefits:
Possible Drawbacks:
Related to:
#2062