Cranelift: ensure ISA level needed for SIMD is present when SIMD is enabled. - #3816
Conversation
a218fb6 to
10db9a6
Compare
github-actions
Bot
added
cranelift
Subscribe to Label Actioncc @peterhuene DetailsThis issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:x64", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
d392b51 to
007eb4d
Compare
|
Pushed updates to propagate through the rest (I only cargo check'd cranelift-codegen and wasmtime-cli before original push) and it seems that |
007eb4d to
20b6fb7
Compare
Yes, it just needed one more tweak (pushed now) -- namely to set SSE3, SSSE3, SSE4.1 on by default for a |
0efa03d to
7b47520
Compare
…nabled. Addresses bytecodealliance#3809: when we are asked to create a Cranelift backend with shared flags that indicate support for SIMD, we should check that the ISA level needed for our SIMD lowerings is present.
7b47520 to
7719a61
Compare
github-actions
Bot
added
the
cranelift:meta
| "SSE3: CPUID.01H:ECX.SSE3[bit 0]", | ||
| false, | ||
| // Needed for default `enable_simd` setting. | ||
| true, |
There was a problem hiding this comment.
This means explicitly using the baseline preset will now incorrectly include these flags, right?
There was a problem hiding this comment.
Will include those flags, yes; "incorrectly" is a matter of interpretation, as we effectively need them at the moment to support our default enable_simd setting. Otherwise a default config will not work with default Wasmtime settings.
There was a problem hiding this comment.
If I enable the baseline preset and not enable_simd, then these features shouldn't be enabled as it won't run on a cpu only implementing the x86_64 baseline. Maybe add them as dependency of enable_simd or enable them in wasmtime?
There was a problem hiding this comment.
We could do it that way as well; happy to take a PR if you want to refactor in that direction. From my point of view, this should be relatively temporary anyway, as we should eventually (#3810) be able to do SIMD without any optional extensions.
Fuzzing over the weekend found that `i64x2` comparison operators require `pcmpgtq` which is an SSE 4.2 instruction. Along the lines of bytecodealliance#3816 this commit unconditionally enables and requires SSE 4.2 for compilation and fuzzing. It will no longer be possible to create a compiler for x86_64 with simd enabled if SSE 4.2 is disabled.
* Enable SSE 4.2 unconditionally Fuzzing over the weekend found that `i64x2` comparison operators require `pcmpgtq` which is an SSE 4.2 instruction. Along the lines of #3816 this commit unconditionally enables and requires SSE 4.2 for compilation and fuzzing. It will no longer be possible to create a compiler for x86_64 with simd enabled if SSE 4.2 is disabled. * Update comment
…nabled. (bytecodealliance#3816) Addresses bytecodealliance#3809: when we are asked to create a Cranelift backend with shared flags that indicate support for SIMD, we should check that the ISA level needed for our SIMD lowerings is present.
* Enable SSE 4.2 unconditionally Fuzzing over the weekend found that `i64x2` comparison operators require `pcmpgtq` which is an SSE 4.2 instruction. Along the lines of bytecodealliance#3816 this commit unconditionally enables and requires SSE 4.2 for compilation and fuzzing. It will no longer be possible to create a compiler for x86_64 with simd enabled if SSE 4.2 is disabled. * Update comment
In bytecodealliance#4224 we saw that an SSE2-only x86-64 system somehow was still detecting SSE3/SSSE3/SSE4.1/SSE4.2. It turns out that we enabled these in the baseline `Flags` in bytecodealliance#3816, because without that, a ton of other things break: default flags no longer produce a compiler backend that works with default Wasmtime settings. However the logic to set them when detected (via `CPUID`-using feature-test macros) only does an "if detected then set bit" step per feature; the bits are never *cleared*. This PR fixes that.
In bytecodealliance#4224 we saw that an SSE2-only x86-64 system somehow was still detecting SSE3/SSSE3/SSE4.1/SSE4.2. It turns out that we enabled these in the baseline `Flags` in bytecodealliance#3816, because without that, a ton of other things break: default flags no longer produce a compiler backend that works with default Wasmtime settings. However the logic to set them when detected (via `CPUID`-using feature-test macros) only does an "if detected then set bit" step per feature; the bits are never *cleared*. This PR fixes that.
…4231) In #4224 we saw that an SSE2-only x86-64 system somehow was still detecting SSE3/SSSE3/SSE4.1/SSE4.2. It turns out that we enabled these in the baseline `Flags` in #3816, because without that, a ton of other things break: default flags no longer produce a compiler backend that works with default Wasmtime settings. However the logic to set them when detected (via `CPUID`-using feature-test macros) only does an "if detected then set bit" step per feature; the bits are never *cleared*. This PR fixes that.
…ytecodealliance#4231) In bytecodealliance#4224 we saw that an SSE2-only x86-64 system somehow was still detecting SSE3/SSSE3/SSE4.1/SSE4.2. It turns out that we enabled these in the baseline `Flags` in bytecodealliance#3816, because without that, a ton of other things break: default flags no longer produce a compiler backend that works with default Wasmtime settings. However the logic to set them when detected (via `CPUID`-using feature-test macros) only does an "if detected then set bit" step per feature; the bits are never *cleared*. This PR fixes that.
4 participants
Addresses #3809: when we are asked to create a Cranelift backend with
shared flags that indicate support for SIMD, we should check that the
ISA level needed for our SIMD lowerings is present.