github-actions[bot] commented on issue #5020:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:meta", "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
afonso360 commented on issue #5020:
This PR had some performance issues:
The regalloc checker started consuming a bunch of time (around 45%) so we now try to minimize runs with it (10% with the current iteration).
I've also had to limit the amount of runs that we allow, at some point the fuzzer decided that spending 100% of the time in the interpreter was a good idea, and started generating huge inputs, that were in the order of 20k runs each. (up to 130k!)
execs/s seems way better than before, which is nice.
And for those who are interested, here's a flamegraph of where we spend time. This is about 1min at 1Khz around 190k inputs into my normal benchmark run:
![flamegraph all](https://user-images.githubusercontent.com/1357143/194936815-38ab0c4c-211c-4828-95fc-ad63e9f5ba74.svg)
afonso360 edited a comment on issue #5020:
This PR had some performance issues:
The regalloc checker started consuming a bunch of time (around 45%) so we now try to minimize runs with it (10% with the current iteration).
I've also had to limit the amount of runs that we allow, at some point the fuzzer decided that spending 100% of the time in the interpreter was a good idea, and started generating huge inputs, that were in the order of 20k runs each. (up to 130k!)
execs/s seems way better than before, which is nice.
And for those who are interested, here's a flamegraph of where we spend time. This is about 2min at 1Khz around 190k inputs into my normal benchmark run:
![flamegraph all](https://user-images.githubusercontent.com/1357143/194936815-38ab0c4c-211c-4828-95fc-ad63e9f5ba74.svg)
afonso360 edited a comment on issue #5020:
This PR had some performance issues:
The regalloc checker started consuming a bunch of time (around 45%) so we now try to minimize runs with it (10% with the current iteration).
I've also had to limit the amount of runs that we allow, at some point the fuzzer decided that spending 100% of the time in the interpreter was a good idea, and started generating huge inputs, that were in the order of 20k runs each. (up to 130k!)
execs/s seems way better than before, which is nice.
And for those who are interested, here's a flamegraph of where we spend time. This is about 2min at 1Khz around 190k inputs into my normal benchmark run:
![flamegraph all](https://user-images.githubusercontent.com/1357143/194936815-38ab0c4c-211c-4828-95fc-ad63e9f5ba74.svg)
Edit: I should note, this is all on top of #5034
afonso360 commented on issue #5020:
I've given this one round of fuzzing on AArch64 and x86, and it found the two issues with
iconst
, one has already been fixed in #5061 and I'm working on removingiconst.i128
, once that is merged I'll give this another round of fuzzing and if everything goes right we should be able to merge this.
afonso360 commented on issue #5020:
@cfallin What do you think about merging this with the
use_egraphs
flag commented out and enabling that on a separate PR?It's getting a bit annoying having to rebase my other work on this PR just to fuzz it. I've fuzzed this for about an hour on both AArch64 and x86 without
use_egraphs
and it seems stable.
cfallin commented on issue #5020:
Oh, for sure, I didn't know we were waiting on something here; sorry! I was waiting for your go-ahead to merge. FWIW the PR is still marked as a draft; go ahead and transition it to "Ready for review" when you want me to merge.
I actually think maybe it's fine to include
use_egraphs
; better to get the fuzzbugs coming sooner than later, and I'm happy to take them as they come in. But I'm open to the other approach if you think otherwise.
afonso360 commented on issue #5020:
Oh, for sure, I didn't know we were waiting on something here; sorry!
I wasn't really, I just got a bit annoyed today at having to do a rebase for the third time, that's where that suggestion came from!I'm okay with merging this as is and letting fuzzgen report issues as we go along.
afonso360 edited a comment on issue #5020:
Oh, for sure, I didn't know we were waiting on something here; sorry!
I wasn't really, I just got a bit annoyed today at having to do a rebase for the third time, that's where that suggestion came from!
I'm okay with merging this as is and letting ossfuzz report issues as we go along.
Last updated: Dec 23 2024 at 12:05 UTC