Wasmtime: run all spec tests with Cranelift-with-egraphs. #5062
Conversation
This change adds another variant of the spec-tests run as part of the `wasmtime-cli` crate's unit tests: Cranelift with egraph-based optimizations enabled. We intend to test egraphs in various ways before turning the mechanism on by default. We will certainly fuzz differentially, but it is also useful to run our basic testsuite against the new compiler mid-end as part of normal CI. There is already precedent for running the spec tests with a variant of settings (the `_pooling` versions of each test). The actual spec testsuite execution does not contribute appreciably to CI time compared to the time to compile Wasmtime itself, so running an extra variant of the tests should not increase test cost significantly.
|
Personally I've found that historically the spec test suite isn't really all that great at exercising compiler internals, so I'd expect to get a lot more bang-for-our-buck by updating fuzzing. Thinking again on this we should probably drop the Is the egraph implementation ready for overall enabling when fuzzing? If not perhaps this option could be added to fuzzing but only enabled for the |
|
Yeah, actually, that's totally fine with me too. Once #5020 lands we'll fuzz with-egraphs against no-egraphs so we'll have full coverage; I was thinking it might be nice to have a stopgap but that's close enough and the spectests are small enough that it's probably not worth it. |
|
It looks like #5020 is only changing the |
|
Yes, actually, we should do that too; I'll follow up with a PR. |
This change adds another variant of the spec-tests run as part of the
wasmtime-clicrate's unit tests: Cranelift with egraph-based optimizations enabled.We intend to test egraphs in various ways before turning the mechanism on by default. We will certainly fuzz differentially, but it is also useful to run our basic testsuite against the new compiler mid-end as part of normal CI. There is already precedent for running the spec tests with a variant of settings (the
_poolingversions of each test). The actual spec testsuite execution does not contribute appreciably to CI time compared to the time to compile Wasmtime itself, so running an extra variant of the tests should not increase test cost significantly.