[hls-fuzzer] Add non-functional fuzzer to bitwidth optimizations#808
Merged
[hls-fuzzer] Add non-functional fuzzer to bitwidth optimizations#808
Conversation
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
force-pushed
the
users/zero9179/bitwidth-non-opt-oracle
branch
from
d4b30b6 to
17a1088
Compare
Jiahui17
reviewed
Mar 24, 2026
Jiahui17
approved these changes
Mar 26, 2026
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.
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
endshould 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 calledhls-fuzzer-check-bitwidth. This enables a nice workflow where reproduction can be done through a simplebash execute.shas is done for the functional testing.The mode is currently selected using a
--non-functionalflag.The PR contains following limitations to be fixed later or simple known issues:
handshake.constantuses unnecassirily large bitwidth after bitwidth optimization #798 which is blocked byinteger bitwidth is limited to 16777215 bitscrash #792 which is blocked by [handshake] Add constant folding toext(u|s)iops #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).