[HandshakeOptimizeBitwidths] Reduce constant op bitwidths#816
Open
[HandshakeOptimizeBitwidths] Reduce constant op bitwidths#816
Conversation
Jiahui17
approved these changes
Mar 26, 2026
zero9178
force-pushed
the
users/zero9179/shrsi-bitwidth
branch
from
dae00eb to
e8a51c0
Compare
zero9178
force-pushed
the
users/zero9179/optimize-constants
branch
from
e5a2da9 to
c5ede00
Compare
zero9178
added a commit
that referenced
this pull request
Mar 29, 2026
Prior to this PR, the pass performed extension of the result of a bounded `cond_br` based on the extension used for the operand. This is incorrect since they have no correlation in the algorithm's logic: The extension that should be used depends on the bound of the data operand, not the data operand itself. More specifically, since the optimization currently only implements unsigned comparisons, the result should then only ever be zero-extended. The only except is for `eq` and `ne` where the result should equal the extend of the constant. Fixes #817 Unblocks #816
zero9178
added a commit
that referenced
this pull request
Mar 30, 2026
Prior to this PR, the pass performed extension of the result of a bounded `cond_br` based on the extension used for the operand. This is incorrect since they have no correlation in the algorithm's logic: The extension that should be used depends on the bound of the data operand, not the data operand itself. More specifically, since the optimization currently only implements unsigned comparisons, the result should then only ever be zero-extended. The only except is for `eq` and `ne` where the result should equal the extend of the constant. Fixes #817 Unblocks #816
zero9178
force-pushed
the
users/zero9179/optimize-constants
branch
2 times, most recently
from
bed97a6 to
ea9b038
Compare
zero9178
added a commit
that referenced
this pull request
Apr 10, 2026
Prior to this PR the cycle bitwidth reduction pattern correctly calculated the optimal bitwidth using backtracking on forwarded branch operands, but failed to do so when determining the extension type. The extension type was instead calculated using the data operands which was incorrect. This resulted in the wrong extension type being calculated at times. This PR fixes that by calculating the extension type and optimal bitwidth of a cyclic mux at the same time. Fixes #827 Required to land #816
zero9178
force-pushed
the
users/zero9179/optimize-constants
branch
from
ea9b038 to
8fc8d4a
Compare
zero9178
force-pushed
the
users/zero9179/optimize-constants
branch
from
8fc8d4a to
e624e4b
Compare
Prior to this PR the bitwidths of constants was reduced by a dedicated pass called `handshake-minimize-cst-width` which would insert `trunci` and `ext`s after reducing the bitwidths of constants. This created a bit of a phase ordering issue however: * Generally speaking we ideally want a single canonical IR form such that all passes can match against that form. Placing `trunci` and `ext` between constants negatively impacts patterns that want to match against constant operands (such as the shift patterns). * The optimize bitwidths pass was then dependent on `minimize-cst-width` running first. If the pass itself created any constants, it'd pessimize optimizations. Additionally, the `minimize-cst-width` pass was too conservative in reducing the bitwidths and would leave sign-bits, even when not necessary. This PR fixes that issue by handling constant ops specially when calculating the "minimal values". Minimal values are now a class that encapsulates the concept of "there exists a minimal value for a value that may be of a smaller bitwidth and can be extended back to the original value". Constant ops are treated as if they were of less bitwidth (equal to the least bitwidth required to represent them) with either sign-extension or zero-extension used depending on whether they were originally negative (to preserve the bit pattern). Fixes #798 Fixes #30 Depends on #815 to not crash
zero9178
force-pushed
the
users/zero9179/optimize-constants
branch
from
e624e4b to
0bf2bf4
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Prior to this PR the bitwidths of constants was reduced by a dedicated pass called
handshake-minimize-cst-widthwhich would inserttrunciandexts after reducing the bitwidths of constants. This created a bit of a phase ordering issue however:trunciandextbetween constants negatively impacts patterns that want to match against constant operands (such as the shift patterns).minimize-cst-widthrunning first. If the pass itself created any constants, it'd pessimize optimizations.Additionally, the
minimize-cst-widthpass was too conservative in reducing the bitwidths and would leave sign-bits, even when not necessary.This PR fixes that issue by handling constant ops specially when calculating the "minimal values". Minimal values are now a class that encapsulates the concept of "there exists a minimal value for a value that may be of a smaller bitwidth and can be extended back to the original value". Constant ops are treated as if they were of less bitwidth (equal to the least bitwidth required to represent them) with either sign-extension or zero-extension used depending on whether they were originally negative (to preserve the bit pattern).
Fixes #798
Fixes #30
Depends on #815 to not crash