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

Add arm64ec support #404

Merged
merged 1 commit into from
Mar 14, 2024
Merged

Add arm64ec support #404

merged 1 commit into from
Mar 14, 2024

Conversation

dpaoliello
Copy link
Contributor

The Rust Compiler has recently added support for ARM64EC (rust-lang/rust#119199), so this change adds support for ARM64EC to portable-simd by enabling the same code as AArch64.

@calebzulawski
Copy link
Member

calebzulawski commented Mar 10, 2024

Since I don't really have any way of testing this--is this truly a different target_arch, rather than a different ABI that modifies target_feature? I ask because it appears to be a variation of aarch64, and there are already lots of checks in both std and community crates that use target_arch = "aarch64" that I would think should automatically support ARM64EC.

@dpaoliello
Copy link
Contributor Author

Since I don't really have any way of testing this--is this truly a different target_arch, rather than a different ABI that modifies target_feature? I ask because it appears to be a variation of aarch64, and there are already lots of checks in both std and community crates that use target_arch = "aarch64" that I would think should automatically support ARM64EC.

Arm64EC isn't just a target feature or ABI of AArch64 - it ends up being a hybrid of AArch64 and x64 where developers need to choose the correct arch to follow at each point.

For intrinsics and assembly, it should reuse the AArch64 code (mostly: the assembly can end up being wildly different depending on what limitations you run into and OS interactions).

However, for interacting with the OS and other applications, then Arm64EC should act like x64. For example, in the backtrace library we use the x64 structs and functions: rust-lang/backtrace-rs#587.

If we were going to make Arm64EC pretend to be another arch, it would be better to treat Arm64EC as a target feature of x64 since using the wrong shape for external APIs is a correctness issue, whereas using the wrong intrinsics can be worked around by reimplementing the x64 intrinsics in AArch64. This is the approach that MSVC has taken, as it sets the predefined macros for x64 not AArch64 and then reimplements the intrinsics in softintrin.lib: https://techcommunity.microsoft.com/t5/windows-os-platform-blog/getting-to-know-arm64ec-defines-and-intrinsic-functions/ba-p/2957235. You can also see from the examples at the end of that article how much of a mess Arm64EC pretending to be x64 turns into. This also doesn't help with assembly: if we ban assembly then that is likely worse than Arm64EC having its own arch (since it guarantees an error, rather than the crate possibly falling back to some default "unknown arch" implementation) but to support it would require outlining the x64 assembly so that LLVM can generate the correct thunks (which feel like a lot of effort to generate suboptimal code).

Instead, for Rust, we decided to make Arm64EC its own arch so that these decisions are explicit, although I do acknowledge that this does create a bunch of work for library maintainers to support yet another arch despite it reusing code from one of the existing archs.

@dpaoliello
Copy link
Contributor Author

For anyone who is interested, there is a good thread over in the stdarch repo on why Arm64EC is its own target_arch: rust-lang/stdarch#1550 (comment)

@calebzulawski calebzulawski merged commit 6aeff2e into rust-lang:master Mar 14, 2024
66 checks passed
@dpaoliello dpaoliello deleted the arm64ec branch March 14, 2024 18:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants