Switch default to new x86_64 backend.

[cfallin]

This PR switches the default backend on x86, for both the
cranelift-codegen crate and for Wasmtime, to the new
(MachInst-style, VCode-based) backend that has been under
development and testing for some time now.

The old backend is still available by default in builds with the
old-x86-backend feature, or by requesting BackendVariant::Legacy
from the appropriate APIs.

As part of that switch, it adds some more runtime-configurable plumbing
to the testing infrastructure so that tests can be run using the
appropriate backend. clif-util test is now capable of parsing a
backend selector option from filetests and instantiating the correct
backend.

I has been updated so that the old x86 backend continues to run its
tests, just as we used to run the new x64 backend separately.

At some point, we will remove the old x86 backend entirely, once we are
satisfied that the new backend has not caused any unforeseen issues and
we do not need to revert.

This implements the switch described in bytecodealliance/rfcs#10; we should
not merge this until we reach consensus on the process described therein
and merge the RFC.

[cfallin]

Switching to "Ready to Review" to get a CI run, but this should still not be merged yet.

[cfallin]

Hmm -- I'm not able to reproduce the segfault with the beta toolchain; I've tested on my usual Fedora 33 and then also Ubuntu 18.04 as GitHub uses. I'm wondering if it may be either a CPU-feature issue or a heisenbug -- will continue to probe at this.

[bjorn3]

I wonder if it would be possible to get GHA to generate a core dump that could be uploaded as artifact.

[cfallin]

On Thu, Mar 25, 2021, at 18:19, Johnnie Birch wrote: ***@***.**** commented on this pull request. In cranelift/filetests/filetests/isa/x64/amode-opt.clif <#2718 (comment)>: > @@ -1,6 +1,5 @@ > test compile > -target x86_64 > -feature "experimental_x64" > +target x86_64 machinst What do the new file test targets (machinst and legacy) mean?

These specify which backend to use to run the test (either new, ie "machinst", or legacy).

[cfallin]

Rebased to latest. The current plan described in the recently merged bytecodealliance/rfcs#10 is to:

1. Wait until next week as the oss-fuzz fuzzers run with the new backend enabled (turned on in Update wasmtime config to use new x86-64 backend. google/oss-fuzz#5518).
2. Make a final release of wasmtime/Cranelift with the current (old) default backend.
3. Review and merge this PR.

[alexcrichton]

FWIW the fuzzers are definitely working because they already fixed a fuzz bug that was about a timeout in the old backend. Our of curiosity is there any particular reason to wait for one more release rather than considering the last release of wasmtime the last release with the old backend as the default?

[cfallin]

That's a good question -- the intent in the RFC was to have a latest-possible snapshot with as many features as possible supported on the old backend with the old backend on by default. Looking through the PR history since 0.25.0, though, it doesn't look like we landed any major user-visible feature, except for some things (SIMD tidbits on new x64 backend, macOS/aarch64) that are not relevant if one is using the old backend. (Please do let me know if I've missed something!)

Given that, I think it fits the spirit of the transition plan in the RFC to take 0.25.0 as the last-good old-backend-as-default release, and just merge this after a bit more fuzzing time. Curious what others think, of course!

[alexcrichton]

Sounds good to me! FWIW this looks good code-wise to me as well

[cfallin]

So there have been no fuzzbugs related to the new backend since we switched the fuzzers over; as per the above, I think this means we're ready to switch the default! Merging now.