Skip to content

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

Open
Roger-luo opened this issue Feb 12, 2025 · 5 comments
Open

global value numbering #239

Roger-luo opened this issue Feb 12, 2025 · 5 comments
Labels
good first issue Good for newcomers pass compiler pass rewrite rewrite related issues

Comments

@Roger-luo
Copy link
Member

this is a quite standard pass we are missing right now.

@weinbe58
Copy link
Member

weinbe58 commented Feb 13, 2025

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.

@kaihsin
Copy link
Contributor

kaihsin commented Feb 16, 2025

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

@Roger-luo
Copy link
Member Author

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)

@kaihsin
Copy link
Contributor

kaihsin commented Feb 17, 2025

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.

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

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)

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?

@kaihsin
Copy link
Contributor

kaihsin commented Feb 27, 2025

maybe related: #270 #267

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers pass compiler pass rewrite rewrite related issues
Projects
None yet
Development

No branches or pull requests

3 participants