NEON not used when compiling for NEON-enabled target without core_arch feature

[hsivonen]

As seen in another issue, when compiling for the thumbv7neon-unknown-linux-gnueabihf target, which supposedly has NEON-enabled core::arch, packed_simd doesn't use NEON. When the core_arch feature is used, packed_simd uses NEON for this target.

Expected packed_simd to use NEON for this target without the core_arch feature by relying on the (supposedly) NEON-enabled core::arch.

[gnzlbg]

This makes sense. I think we don't have any build jobs for those targets, so that would be the most difficult part of implementing and testing this. Do you know any projects testing these targets on CI, e.g., using qemu or similar ? I'll submit a PR to fix this without any tests beside build tests in the meantime.

[hsivonen]

Do you know any projects testing these targets on CI, e.g., using qemu or similar ?

I'm not aware on anyone using these targets besides myself on my development machine at this time. I introduced the thumbv7neon targets with the assumption that Firefox would need to use them in order for core::arch code to inline properly into packed_simd, but Firefox doesn't use the targets yet. Once the Firefox bug to adopt these targets is fixed, Firefox would run the Android target in CI in a way that would check that code compiles and runs, but not in a way that would actually catch performance regressions or specific instruction selection regressions.

[gnzlbg]

Sadly, this isn't as easy as I thought.

The problem is that there is no way to query whether libcore was compiled with neon enabled or not.

That is, packed_simd cannot tell whether you are building for thumbv7neon-unknown-linux-gnueabihf, whose libcore was compiled with NEON, or armv7-unknown-linux-gnueabihf -C target-feature=+neon, whose libcore was compiled without NEON.

thumbv7neon-unknown-linux-gnueabihf does never need to compile core_arch, while armv7-unknown-linux-gnueabihf -C target-feature=+neon might want to re-compile core_arch with NEON enabled or not.

I might be able to hack something in the Cargo.toml, e.g., to always enable a libcore_neon feature for targets that have a libcore compiled with neon, otherwise I think we will need to do this in a build.rs (e.g. if the TARGET triple contains neon, then don't require core_arch).

[gnzlbg]

This bug should be fixed in version 0.3.3.

[hsivonen]

Confirming that this is now fixed. Thank you!