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

Cranelift: ensure ISA level needed for SIMD is present when SIMD is enabled. #3816

Merged
merged 1 commit into from
Feb 17, 2022

Conversation

cfallin
Copy link
Member

@cfallin cfallin commented Feb 16, 2022

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.

@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:area:aarch64 Issues related to AArch64 backend. cranelift:area:x64 Issues related to x64 codegen wasmtime:api Related to the API of the `wasmtime` crate itself labels Feb 16, 2022
@github-actions
Copy link

Subscribe to Label Action

cc @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:

  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@cfallin cfallin force-pushed the simd-require-sse41 branch 2 times, most recently from d392b51 to 007eb4d Compare February 16, 2022 21:54
@cfallin
Copy link
Member Author

cfallin commented Feb 16, 2022

Pushed updates to propagate through the rest (I only cargo check'd cranelift-codegen and wasmtime-cli before original push) and it seems that Engine::default() is actually giving an Engine without the right CPU flags to allow for SIMD; this is somewhat perplexing and I'll look into it further.

Copy link
Contributor

@abrown abrown left a 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?

@cfallin
Copy link
Member Author

cfallin commented Feb 17, 2022

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?

Yes, it just needed one more tweak (pushed now) -- namely to set SSE3, SSSE3, SSE4.1 on by default for a Flags that is constructed manually (vs. from cranelift_native); otherwise a wasmtime compile fails because SIMD is on by default, and the CLI machinery sets an explicit target which establishes default feature flags.

@cfallin cfallin force-pushed the simd-require-sse41 branch 2 times, most recently from 0efa03d to 7b47520 Compare February 17, 2022 00:14
…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.
@github-actions github-actions bot added the cranelift:meta Everything related to the meta-language. label Feb 17, 2022
@cfallin cfallin merged commit 1c014d1 into bytecodealliance:main Feb 17, 2022
@cfallin cfallin deleted the simd-require-sse41 branch February 17, 2022 01:29
@@ -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,
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Feb 22, 2022
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.
alexcrichton added a commit that referenced this pull request Feb 22, 2022
* 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
mpardesh pushed a commit to avanhatt/wasmtime that referenced this pull request Mar 17, 2022
…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.
mpardesh pushed a commit to avanhatt/wasmtime that referenced this pull request Mar 17, 2022
* 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
cfallin added a commit to cfallin/wasmtime that referenced this pull request Jun 6, 2022
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.
cfallin added a commit to cfallin/wasmtime that referenced this pull request Jun 6, 2022
 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.
cfallin added a commit that referenced this pull request Jun 8, 2022
…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.
Stebalien pushed a commit to filecoin-project/wasmtime that referenced this pull request Jun 9, 2022
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:aarch64 Issues related to AArch64 backend. cranelift:area:x64 Issues related to x64 codegen cranelift:meta Everything related to the meta-language. cranelift Issues related to the Cranelift code generator wasmtime:api Related to the API of the `wasmtime` crate itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants