-
Notifications
You must be signed in to change notification settings - Fork 1
global value numbering #239
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
Comments
How is this different from CSE? The only difference is how you could possible implement it, e.g., you could use hashing for this pass but that's not the only why to check equivalence between constant statements. |
This is a bit tricky because kirin allow arbitrary python class as constant. I am thinking we only check and eliminate constant that are only hashable |
That's not true, we assume "all attributes are hashable". Read the implementation of CSE, and note that GVN is not the same as CSE, a lot of redundancy is already removed today when you run CSE. One the other hand, I'm not sure if we really should push this to far (about checking SSAValue equivalence) - the gain does not seem to worth the cost not to say one day we will still move part of the compilation into low-level infrastructure (e.g MLIR or Julia) |
I know CSE assume that, but then shouldn't we guard this at the lowering already? right now we allow arbitrary capture python runtime to be constant
Then I guess I am confused. What is this actually want address in this issue? It seems GVN can be achieved by composition the rules we already have (unless there is any we can't?) Or this is for performance consideration? |
this is a quite standard pass we are missing right now.
The text was updated successfully, but these errors were encountered: