[handshake] Add constant folding to ext(u|s)i ops#802
Merged
Conversation
No constant folding of these ops existed up until now. Having these kinds of constant folding is useful besides being an optimization, since it allows code to assume that if an operand can be calculated as a constant, it'll be a constant. This PR adds such a constant folding pattern for `extui` and `extsi` ops. Part of #792
Member
|
there are some tests contain hardcoded op names, emmet is fixing them (#793 |
This reverts commit cedb7dd.
Collaborator
Author
Is there any way to "regenerate" the buffer.json file or is this handcrafted? |
Member
|
They are handcrafted |
Collaborator
|
Do I need to fix the speculator also to avoid blocking this or just the buffering? @Jiahui17 |
Member
|
@murphe67 Just buffering should be good (placing the speculator at qualitatively the same location seems straightforward |
zero9178
added a commit
that referenced
this pull request
Mar 23, 2026
With the recently landed bitwidth type system we have an initial generator that is capable of generating C programs known to compute under a given bitwidth. The initial PR used this for functional testing, where the programs generated are simply more likely to trigger mis-compilations in the optimization pass. The new non-functional oracle introduced in this PR tests the optimization capabilities of the pass: It checks the output IR for any computations that are done at a higher bitwidth than expected. The logic for doing so is currently simple: All results of operations that aren't operands of an `end` should be done using a bitwidth that is at most equal to the bitwidth the generator used. The logic for this is via a separate oracle executable called `hls-fuzzer-check-bitwidth`. This enables a nice workflow where reproduction can be done through a simple `bash execute.sh` as is done for the functional testing. The mode is currently selected using a `--non-functional` flag. The PR contains following limitations to be fixed later or simple known issues: * It finds bugs very, very quickly due to: #798 which is blocked by #792 which is blocked by #802. I manually verified some bugs it found that the logic ought to work, but it is hard to say until we get more usage. As a drive-by fix, also disable right-shift generation for now (the logic was incorrect and was accidentally included).
zero9178
added a commit
that referenced
this pull request
Mar 23, 2026
With the recently landed bitwidth type system we have an initial generator that is capable of generating C programs known to compute under a given bitwidth. The initial PR used this for functional testing, where the programs generated are simply more likely to trigger mis-compilations in the optimization pass. The new non-functional oracle introduced in this PR tests the optimization capabilities of the pass: It checks the output IR for any computations that are done at a higher bitwidth than expected. The logic for doing so is currently simple: All results of operations that aren't operands of an `end` should be done using a bitwidth that is at most equal to the bitwidth the generator used. The logic for this is via a separate oracle executable called `hls-fuzzer-check-bitwidth`. This enables a nice workflow where reproduction can be done through a simple `bash execute.sh` as is done for the functional testing. The mode is currently selected using a `--non-functional` flag. The PR contains following limitations to be fixed later or simple known issues: * It finds bugs very, very quickly due to: #798 which is blocked by #792 which is blocked by #802. I manually verified some bugs it found that the logic ought to work, but it is hard to say until we get more usage. As a drive-by fix, also disable right-shift generation for now (the logic was incorrect and was accidentally included).
zero9178
added a commit
that referenced
this pull request
Mar 26, 2026
With the recently landed bitwidth type system we have an initial generator that is capable of generating C programs known to compute under a given bitwidth. The initial PR used this for functional testing, where the programs generated are simply more likely to trigger mis-compilations in the optimization pass. The new non-functional oracle introduced in this PR tests the optimization capabilities of the pass: It checks the output IR for any computations that are done at a higher bitwidth than expected. The logic for doing so is currently simple: All results of operations that aren't operands of an `end` should be done using a bitwidth that is at most equal to the bitwidth the generator used. The logic for this is via a separate oracle executable called `hls-fuzzer-check-bitwidth`. This enables a nice workflow where reproduction can be done through a simple `bash execute.sh` as is done for the functional testing. The mode is currently selected using a `--non-functional` flag. The PR contains following limitations to be fixed later or simple known issues: * It finds bugs very, very quickly due to: #798 which is blocked by #792 which is blocked by #802. I manually verified some bugs it found that the logic ought to work, but it is hard to say until we get more usage. As a drive-by fix, also disable right-shift generation for now (the logic was incorrect and was accidentally included).
zero9178
added a commit
that referenced
this pull request
Mar 27, 2026
The previous logic for `shrui` for the forward pass did not properly handle sign-extension for `shrui`, resulting in sign-extension of the result often being performed in cases where the shifting should fill in 0 bits. Furthermore, if the constant was larger than the minimal input bitwidth, integer overflow would occur in the implementation causing crashes. This PR fixes that issue by splitting the forward pass for `shrui` out of the common shift pattern and taking both zero-extension and sign-extension of the input into account. I believe the logic of `shrui` and `shrsi` to likely be different enough to require different forwarding patterns. The older generic `ArithShift` pattern remains in use for the backward pass. Fixes #792 Depends on #802 to function
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
3 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.
No constant folding of these ops existed up until now. Having these kinds of constant folding is useful besides being an optimization, since it allows code to assume that if an operand can be calculated as a constant, it'll be a constant.
This PR adds such a constant folding pattern for
extuiandextsiops.Part of #792