rust should not assume NEON on armhf

[sylvestre]

Reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834003
To quote Steve:

None of the Linux distros doing ARMv7 hard-float assume
NEON. The spec was agreed across the distros to explicitly not
depend on NEON for these ports because it's optional and there
are/were a number of ARMv7 CPUs in the wild without it.

[lucab]

/cc @alexcrichton @fabricedesre @petevine

This is seems to be coming from #30948 (comment). I guess this may have gone unnoticed so far because original porting has been done on a RPi2 with NEON.

[MagaTailor]

That's correct, strictly speaking, as originally there was just one armhf triple and it defaulted to ARMv6. (the current arm-unknown-). It was never a problem because rust std library remains minimalistic and most of the code has to be compiled from crates. (that's when -C target-cpu and -C target-feature kick in and the resulting code suffers no penalty)

However, if the official distribution methods start detecting the ISA correctly, it should be possible to add as many combinations as required. Personally, I don't like the potential fragmentation, so if it were up to me, I'd advise using the arm- triple and tweaking the codegen, either via patches or a wrapper script.

Oh, and I fully expect vfpv3-d16 coming next.

[Amanieu]

Only the armv7-unknown-linux-gnueabihf target uses neon. In particular, the arm-unknown-linux-gnueabihf (note the lack of v7) target does not. It seems to me that this issue can be solved by having debian armhf use the arm-unknown-linux-gnueabihf target instead.

[infinity0]

That optimises for arm v6 so it wouldn't be ideal.

mk/cfg/arm-unknown-linux-gnueabihf.mk:CFG_JEMALLOC_CFLAGS_arm-unknown-linux-gnueabihf := -D__arm__ $(CFLAGS) -march=armv6 -marm
mk/cfg/arm-unknown-linux-gnueabihf.mk:CFG_GCCISH_CFLAGS_arm-unknown-linux-gnueabihf := -Wall -g -fPIC -D__arm__ $(CFLAGS) -march=armv6 -marm
mk/cfg/arm-unknown-linux-gnueabihf.mk:RUSTC_FLAGS_arm-unknown-linux-gnueabihf := -C target-feature=+v6,+vfp2

[MagaTailor]

On the other hand, I might be privvy to one little tidbit why the targets might not be equivalent nowadays, but only in the case of mixed C,C++/Rust codebases, namely the gcc-rs crate.

It forces -march=armv6 for the arm- target which is obviously necessary for cross-compilation but leads to benchmarkable performance loss on an ARMv7 system (see parity) so an unsuspecting user might get tripped.

[MagaTailor]

@infinity0 This is why you'd have to tweak the codegen, preferably via a wrapper script, in which case the target can be used as is.

[lucab]

What we are arguing here is that rustc has two profiles for gnueabihf targets, none of which corresponds to the traditional definition of Linux ARMv7-HF ports.

While above suggestions of probing the ISA, picking another target, and tweaking codegen are perfectly fine solution for specific users/machines, this doesn't work in the context of packaged binaries (which are moved across machines) and need to agree on the baseline architecture definition.

In this specific case, rust should decide which profile is the canonical target for a Linux ARMv7-HF port, and align it to the agreed definition of that architecture baseline: armv7+thumb2+VFP3D16

[Amanieu]

The Rust ARM targets don't line up with the debian/gnu ones at all.

Rust:

• arm-unknown-linux-gnueabi: ARMv6, soft float
• arm-unknown-linux-gnueabihf: ARMv6, VFPv2
• armv7-unknown-linux-gnueabihf: ARMv7, VFPv3 + NEON

Debian/GNU:

• armel/arm-linux-gnueabi: ARMv4t, soft float
• armhf/arm-linux-gnueabihf: ARMv7, VFPv3 (no NEON)

I still think the best solution in this case would be for Debian armhf to use the arm-unknown-linux-gnueabihf Rust target.

[MagaTailor]

@lucab That's precisely what myself and @Amanieu meant - binaries would have to be built with the following command:

rustc --target=arm-unknown-linux-gnueabihf -C target-cpu=cortex-a8 -C target-feature=+v7,+thumb2,+vfp3,+d16

[alexcrichton]

Thanks for the report @lucab and @sylvestre! I believe @Amanieu correctly summarized the Rust state of affairs here, but could you confirm the Debian/GNU state of affairs? It'd be helpful to understand what exactly the targets Linux distros are expecting and how they're compiled.

This was also discussed previously here I believe.

cc @larsbergstrom, I think Servo wants NEON on for sure, right?
cc @japaric

[anguslees]

@alexcrichton: I confirm @Amanieu's Debian summary above. Ignoring obsolete/historical ARM ports, Debian now has:

• armel: ARMv4t, soft float. https://wiki.debian.org/ArmEabiPort
• armhf: ARMv7, thumb2, VFP3D16 (no NEON). https://wiki.debian.org/ArmHardFloatPort
• arm64: ARMv8, 64bit. https://wiki.debian.org/Arm64Port

[sanxiyn]

This was also discussed in #31800.

As I understand, the only reason Rust ARM is v6 is to support original RPi. I objected this does not match the traditional definition. @alexcrichton decided to just ignore the definition, since RPi needs to be supported. See #31800 for details.

[glandium]

Why not support the original RPi with an explicit armv6 triplet?

[sanxiyn]

Indeed. My proposal is: 1. Align Rust gnueabi/gnueabihf to v4/v7. 2. Keep (now misnamed) Rust armv7 for v7+neon. 3. Since RPi is weird, create new target just for RPi.

[Amanieu]

Rust requires at least ARMv6, since previous versions of the architecture don't support atomic operations.