-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Cranelift: ensure ISA level needed for SIMD is present when SIMD is enabled. #3816
Conversation
a218fb6
to
10db9a6
Compare
Subscribe to Label Actioncc @peterhuene
This 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this makes sense to me. @cfallin, don't know if I understand your last comment: does your latest commit fix the issue or are more changes required?
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
@@ -17,19 +17,22 @@ fn define_settings(shared: &SettingGroup) -> SettingGroup { | |||
"has_sse3", | |||
"Has support for SSE3.", | |||
"SSE3: CPUID.01H:ECX.SSE3[bit 0]", | |||
false, | |||
// Needed for default `enable_simd` setting. | |||
true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means explicitly using the baseline preset will now incorrectly include these flags, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.