mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-22 01:35:35 +00:00
d4ea925beb
When enabling neon (--with-fpu=neon, or when the C++ compiler defaults to use neon), we pass +neon as a target feature to the rust compiler. That enables neon in rust, which is the default with the thumbv7neon-linux-gnueabihf rust target, but not the default for the armv7-unknown-linux-gnueabihf rust target. ARM processors may have various different FPUs, with different number of registers. On ARMv7, there are FPUs with 16 registers and FPUs with 32 registers. NEON requires 32 registers. Because the common denominator for ARMv7 is 16 registers, the armv7-unknown-linux-gnueabihf rust target defaults to 16 registers, although by enabling neon, we're guaranteed the processor will have 32. But while the rust compiler keeps limited to 16 registers, it also hits a wall while compiling the hyper crate, where it finds it doesn't have enough registers (which in itself can be considered a bug). Since enabling neon means there are 32 registers available, it makes sense to tell the compiler to lift the restricted use of FPU registers, and that's what the `-d16` target feature does. That's the default for the thumbv7neon-linux-gnueabihf rust target, so nothing is changed, there, and fixes things for the armv7-unknown-linux-gnueabihf rust target. Differential Revision: https://phabricator.services.mozilla.com/D33907 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| xpidl | ||
| autotargets.mk | ||
| debugmake.mk | ||
| functions.mk | ||
| makeutils.mk | ||
| nonrecursive.mk | ||
| rust.mk | ||
| target_binaries.mk | ||