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

(Re-)Introduce ARMv7+NEON Android and GNU/Linux targets #49897

Closed
hsivonen opened this issue Apr 12, 2018 · 5 comments
Closed

(Re-)Introduce ARMv7+NEON Android and GNU/Linux targets #49897

hsivonen opened this issue Apr 12, 2018 · 5 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-android Operating system: Android O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@hsivonen
Copy link
Member

Even though ARMv7 Android doesn't guarantee the presence of NEON, most devices have it and e.g. Firefox opts not to support ARMv7 devices that don't have it. (Notably the Tegra 2-based ones.)

To allow Rust code, including the standard library, to unconditionally use NEON in such a scenario, it would help a lot if upstream Rust supported an ARMv7+NEON Android target. (NEON support was explicitly removed from armv7-linux-androideabi.

In order to test code on a system that has all the usual tooling, it's useful to have a corresponding GNU/Linux target, too. NEON was explicitly removed from armv7-unknown-linux-gnueabihf and also from armv7-unknown-linux-musleabihf.

Please add new androideabi and gnueabihf ARMv7 targets that have NEON enabled and a NEON-enabled standard library shipped via rustup so that std::simd ends up compiled with NEON enabled. (See the issue about boolean reductions there.)

How to name these is a total bikeshed, but as a starting point, I suggest armv7neon-unknown-linux-gnueabihf and armv7neon-linux-androideabi.

@gnzlbg
Copy link
Contributor

gnzlbg commented Apr 12, 2018

Note that aarch64 has the same issue, so it might be worth it to add the aarch64neon-unknown-linux-gnu and aarch64neon-linux-android targets as well. Maybe also aarch64neon-apple-ios :/

@hsivonen
Copy link
Member Author

I thought that ARMv8 guaranteed 128-bit SIMD support like x86_64 guarantees SSE2. Is that not the case?

@hsivonen
Copy link
Member Author

It seems that Rust's aarch64-unknown-linux-gnu target feels eligible to generate ldr q0, [x0] for loading an u8x16 from memory.

Programmer’s Guide for ARMv8-A says:

Both floating-point and NEON are required in all standard ARMv8 implementations. However, implementations targeting specialized markets may support the following combinations:

  • No NEON or floating-point.
    ...

I would hope that the Rust built-in aarch64 targets were for "standard implementations" and not for "specialized markets", so if they fail to allow some NEON instructions, we should probably edit those targets in place instead of introducing aarch64neon variants. But, as noted, aarch64 in Rust seems to allow 128-bit SIMD already.

@gnzlbg
Copy link
Contributor

gnzlbg commented Apr 12, 2018

I just tried it on stdsimd and aarch64-unknown-linux-gnu does indeed have neon/asimd always enabled :)

@XAMPPRocky XAMPPRocky added C-enhancement Category: An issue proposing an enhancement or a PR with one. O-android Operating system: Android O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 7, 2018
@hsivonen
Copy link
Member Author

These were added in #49902.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-android Operating system: Android O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants