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.
👋 Hey,
Following up from #4884 (Thanks!) this PR introduces
fcvt_*
ops to the fuzzer. Additionally it also adds a pass to minimize the number of traps generated by these ops.Like the
int_divz
pass, the number of traps generated doesn't seem to correspond with the amount requested in the config. I think I've actually figured out something here, if I limit the amount of bytes the fuzzer uses, the amount of traps is reduced by a lot. (I got 0.4%int_ovf
with-max_len=2048
)That leads me to believe that we get such a high number of traps due to executing a lot of inputs. This is something that I want to look further into since I think there could actually be a performance benefit from limiting this.
As a sanity check I also tried to benchmark with 100% insertion rate, and as expected we don't get the other traps.
Benchmarks
Baseline
This PR
I've seen the
int_ovf
trap count vary a lot while testing, from 0.4% up to almost 7%.This PR while always applying the trap pass
cc: @jameysharp