-
Notifications
You must be signed in to change notification settings - Fork 72
Turn constant folder and dce into passes #2109
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
Conversation
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.
Pull Request Overview
This PR refactors the optimizer by turning the constant folding and dead code elimination logic into individual passes. Key changes include:
- Renaming and refactoring the unused nodes removal functionality into a new RemoveUnusedNodesPass class.
- Replacing the old ConstantFolder class with a new FoldConstantsPass class that conforms to the PassBase API.
- Updating related call sites and ensuring modification tracking is consistently applied.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
File | Description |
---|---|
onnxscript/optimizer/_remove_unused.py | Renames an internal function and replaces a standalone function with a class. |
onnxscript/optimizer/_constant_folding.py | Refactors constant folding into a pass-based API and updates modification logic. |
Comments suppressed due to low confidence (2)
onnxscript/optimizer/_remove_unused.py:58
- [nitpick] The renaming of 'process_function_or_graph' to '_process_function_or_graph' clarifies its internal usage. Consider adding a brief docstring to summarize its behavior for future maintainers.
def _process_function_or_graph(function_or_graph: ir.Function | ir.Graph) -> int:
onnxscript/optimizer/_constant_folding.py:1016
- Ensuring the modification flag is set after node replacement is crucial; verify that similar modifications in other code paths consistently update this flag.
self.modified = True
❌ 11 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
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.
This looks fine, thanks.
What would be interesting (but is not clear yet to me) is how we use passes effectively and whether that requires other abstractions. For example, I see that the PassManager allows execution of a sequence of passes (iteratively). Would we need the ability to turn a sequence of passes (may be even an iteration N times) into a pass (which can itself then be used as one pass among another sequence of passes)? Essentially a "Sequence of Passes" as a "Pass"?
Of course, that leads to other ways of composing passes (eg. "pass1 OR pass2": in ORT fusion context, there is the possibility that we try GQA fusion only if MHA fusion fails). Of course, this may end up encoding a full programming-language within passes ... but that may be a bit too much right now, and it seems easier to use Python to express compositions for right now.
Sure! PassManager itself can be used as a pass. Something that is specialized for that will work too. |
Turn constant folder and dce into passes to allow them to be used as individual passes in the future.
Turn constant folder and dce into passes to allow them to be used as individual passes in the future.
Turn constant folder and dce into passes to allow them to be used as individual passes in the future.
Turn constant folder and dce into passes to allow them to be used as individual passes in the future.
@gramalingam