Support stable Rust on 32-bit ARM

[laurens-pilot]

Summary

This removes the nightly-only 32-bit ARM stdarch_arm_feature_detection gate by avoiding runtime ARM feature detection on target_arch = "arm".

On 32-bit ARM, std::arch::is_arm_feature_detected! still requires nightly. This means crates depending on rav1d cannot build for 32-bit ARM targets with stable Rust.

Instead, this patch uses the stable #[cfg(target_feature = "neon")] compile-time fallback for 32-bit ARM and leaves the existing runtime detection paths for other architectures unchanged.

Details

• Removes #![cfg_attr(target_arch = "arm", feature(stdarch_arm_feature_detection))]
• Replaces 32-bit ARM runtime detection for neon with #[cfg(target_feature ="neon")]
• Does not change the aarch64 runtime detection path

The tradeoff is that on 32-bit ARM this only enables NEON when it is known at compile time. That seems preferable to requiring nightly for all stable 32-bit ARM consumers.

Testing

Tested locally with stable Rust:

cargo +stable check --lib --no-default-features --features bitdepth_8,bitdepth_16
cargo +stable check --lib --target armv7-linux-androideabi --no-default-features
--features bitdepth_8,bitdepth_16

[thedataking]

Thanks for your PR!

The tradeoff is that on 32-bit ARM this only enables NEON when it is known at compile time. That seems preferable to requiring nightly for all stable 32-bit ARM consumers.

I disagree. It does not seem preferable to do runtime feature detection on some targets (arm32) and compile-time detection on others. Consistency between the different targets and consistency with dav1d makes troubleshooting, maintenance, and performance analysis simpler; we should keep it that way!

At a more fundamental level, I think we need feature detection to happen at runtime. Rav1d is intended to be compiled on one machine and distributed to many others. Choosing features at compile time would either exclude arm32 targets that do not have neon or forego neon acceleration on targets that do have the feature. Neither option is acceptable.

If there is no way to support runtime feature-detection on stable Rust, I'm afraid this PR must block on stabilization or we need to look for an acceptable workaround.