Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzing: add use_egraphs option back to fuzzing config generator. #5388

Merged
merged 1 commit into from
Dec 7, 2022

Conversation

cfallin
Copy link
Member

@cfallin cfallin commented Dec 6, 2022

This PR reverts #5128 (commit b3333bf), adding back the ability for the fuzzing config generator to set the use_egraphs Cranelift option. This will start to fuzz the egraphs-based optimization framework again, now that #5382 has landed.

This PR reverts bytecodealliance#5128 (commit b3333bf),
adding back the ability for the fuzzing config generator to set
the `use_egraphs` Cranelift option. This will start to fuzz the
egraphs-based optimization framework again, now that bytecodealliance#5382 has landed.
@cfallin cfallin requested review from fitzgen and jameysharp December 6, 2022 23:46
@cfallin cfallin enabled auto-merge (squash) December 7, 2022 00:01
@cfallin cfallin merged commit 0eb2242 into bytecodealliance:main Dec 7, 2022
@cfallin cfallin deleted the egraph-fuzzing branch December 7, 2022 00:49
cfallin added a commit that referenced this pull request Jan 19, 2023
This PR follows up on #5382 and #5391, which rebuilt the egraph-based optimization framework to be more performant, by enabling it by default.

Based on performance results in #5382 (my measurements on SpiderMonkey and bjorn3's independent confirmation with cg_clif), it seems that this is reasonable to enable. Now that we have been fuzzing compiler configurations with egraph opts (#5388) for 6 weeks, having fixed a few fuzzbugs that came up (#5409, #5420, #5438) and subsequently received no further reports from OSS-Fuzz, I believe it is stable enough to rely on.

This PR enables `use_egraphs`, and also normalizes its meaning: previously it forced optimization (it basically meant "turn on the egraph optimization machinery"), now it runs egraph opts if the opt level indicates (it means "use egraphs to optimize if we are going to optimize"). The conditionals in the top-level pass driver are a little subtle, but will get simpler once we can remove the non-egraph path (which we plan to do eventually!).

Fixes #5181.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants