-
Notifications
You must be signed in to change notification settings - Fork 269
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
wazevo: initial work on constant folding #1851
Closed
Closed
Changes from 14 commits
Commits
Show all changes
23 commits
Select commit
Hold shift + click to select a range
362a730
wip: constant folding
evacchi fe56392
wip
evacchi d68ac6b
wip
evacchi 10f0f22
wip
evacchi 87e4453
valueIDToInstruction should be always re-inited
evacchi 48bf12d
valueIDToInstruction does not have to be cleared explicitly
evacchi 82d6f04
wip
evacchi 500aa54
operands were not actually cleared! (not reset to ValueInvalid)
evacchi 7a08db7
add more cases
evacchi 6c10833
add tests for mul and floats
evacchi 073789c
passCollectValueIdToInstructionMapping is its own pass
evacchi e01691c
deduplicate code in pass deadcode elim
evacchi fdcc3c7
fixed point is local to each basic block
evacchi 2842b95
more test cases
evacchi 2f76dad
float cases
evacchi cddeb20
use %g to format float constants (ssa)
evacchi c8ec025
simplify constFold
evacchi 2686b57
some work on algebraic simplification for Iadd
evacchi 1590119
add more cases, perf still not particularly interesting
evacchi 796b969
wip
evacchi a4b5549
wip
evacchi d9a81d3
format
evacchi 7ff5155
remove useless extra pass
evacchi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
Oops, something went wrong.
Oops, something went wrong.
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.
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.
yeah I think I would suggest to see how much overhead costs will be added like by compiling zig stdlib binray and let's have a reasonable O(1) upper bound
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.
even without an upper bound the pass seems to account for less than 1% CPU time against the Wasm library.
in terms of hard numbers, on my machine it compiles the wasm binary in about 7.02 seconds with the extra pass and 6.94-6.99 without
To be fair, that might not be surprising: e.g., if the wasm binary went through
wasm-opt
it might be already minimized, and if it weren't, operations between constants may not naturally occur in a Wasm binary very often (after all, it's already a compilation target)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.
...in fact, I am not even sure how often this pass will be useful, I don't know how often we'll find cases in the wild. Anyway it's a useful playground for me...
Besides, other, related techniques such as constant tracking and constant propagation might still be beneficial, and the framework should be similar.
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.
I figured out what (silly) mistake I was making with my experiment with algebraic simplification (just
add X, const1; add Y, const2 => add X, (const1+const2)
). This, together with const-fold adds a more significant overhead (~7.4); but that should also mean that it does make some difference. On a first quick look, the first largest functions in the zig stdlib were not significantly smaller.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.
Memo to self https://developers.redhat.com/articles/2023/12/07/how-single-iteration-instcombine-improves-llvm-compile-time#removing_the_fixpoint_iteration
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.
The diff in the size(?) seems negligible to me even with simplification…
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.
yeah agreed (yeah that's size in bytes)