support hardware sqrt for f32 on arm32 targets

[silverstillisntgold]

Following up on this discussion.

Currently this uses a bit of a janky trick to work around a rustc bug. Since we can't use sreg to operate on input x in-place, we instead cast it to an integer, load it into an integer register, then move it to a floating point register where we can use sqrt. A little annoying, but 3 instructions is still far better than a whole software sqrt routine lol. Hopefully the fix for the bug will land in the next couple of weeks and will be in stable 1.100.0. The original bug report can be found here.

I tried to mimic the structure of previous implementations, but let me know if anything should be changed. Was also going to do the f64 sqrt variant for chips like the M7, M55, M85, etc., but I'm not sure there's currently a reliable (and stable) way to detect both HF ABI and fp64 support.

[silverstillisntgold]

seems like I murdered CI

[silverstillisntgold]

Seems like the only failure is on the libm MSRV check due to the use of target_abi for ensuring hardware FP support. Looks like this feature was stabilized in 1.78.0 (released on May 2, 2024). Unfortunate. Guess that puts this PR on the backburner until a 0.3 release alongside an MSRV bump?

[tgross35]

The ABI thing can be worked around with the build script: update

compiler-builtins/libm/configure.rs

Lines 99 to 126 in b2a59c9

	let split = &cfg.target_triple_split;
	let unstable_float = cfg!(feature = "unstable-float");
	// Intrinsics may include `core::arch` use, so also gate it under `arch`.
	let intrinsics_enabled = cfg!(feature = "unstable-intrinsics") && cfg!(feature = "arch");
	// Some tests are extremely slow. Emit a config option based on optimization level.
	let opt = !matches!(cfg.opt_level.as_str(), "0" | "1");
	// To compile builtins-test-intrinsics for thumb targets, where there is no libc
	let thumb = split[0].starts_with("thumb");
	// compiler-rt `cfg`s away some intrinsics for thumbv6m and thumbv8m.base because
	// these targets do not have full Thumb-2 support but only original Thumb-1.
	// We have to cfg our code accordingly.
	let thumb_1 = split[0] == "thumbv6m" || split[0] == "thumbv8m.base";
	// Shorthand to detect i586 targets
	let x86_no_sse2 = cfg.target_arch == "x86" && !cfg.target_features.iter().any(|f| f == "sse2");
	// If set, enable `no-panic` for `libm`. Requires LTO (`release-opt` profile).
	let assert_no_panic = env_flag("ENSURE_NO_PANIC");
	// Arch shorthand config is used in most crates.
	set_cfg("thumb", thumb);
	set_cfg("thumb_1", thumb_1);
	set_cfg("x86_no_sse2", x86_no_sse2);

with a target_abi_eabihf and target_abi_eabi, after picking up CARGO_CFG_TARGET_ABI.

It looks like you could also check for the fpregs without soft-float? I'm not sure whether that's more accurate. @taiki-e you may have some thoughts here.

$ diff -up <(rustc --print cfg --target armv7-unknown-linux-gnueabi) <(rustc --print cfg --target armv7-unknown-linux-gnueabihf)
--- /dev/fd/63  2026-08-25 21:04:43
+++ /dev/fd/62  2026-08-25 21:04:43
@@ -3,7 +3,7 @@ relocation_model="pic"
 overflow_checks
 panic="unwind"
 relocation_model="pic"
-target_abi="eabi"
+target_abi="eabihf"
 target_arch="arm"
 target_endian="little"
 target_env="gnu"
@@ -12,7 +12,6 @@ target_feature="fpregs"
 target_feature="d32"
 target_feature="dsp"
 target_feature="fpregs"
-target_feature="soft-float"
 target_feature="thumb2"
 target_feature="v5te"
 target_feature="v6"

Is sqrt available in the fpregs baseline?

[silverstillisntgold]

Hadn't even considered utilizing the build script, that might also make it easy to implement f64 sqrt. I was initially avoiding using target-features since that approach falls apart when building using the thumb targets for embedded.

rustc --print cfg --target thumbv8m.main-none-eabihf
debug_assertions
panic="abort"
target_abi="eabihf"
target_arch="arm"
target_endian="little"
target_env=""
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_primitive_alignment="16"
target_has_atomic_primitive_alignment="32"
target_has_atomic_primitive_alignment="8"
target_has_atomic_primitive_alignment="ptr"
target_os="none"
target_pointer_width="32"
target_vendor="unknown"

The output is identical for thumbv7em-none-eabihf and both non-hf variants.

[tgross35]

Isvsqrt.f64 available with the vfp2 target feature? Seems to be the case based on https://rust.godbolt.org/z/5hdce3EGK. If so, it should be fine to add a f64 version gated on that, similar to what is done with sqrtf16 on aarch64.

(Please confirm what vfp2 actually enables)

[tgross35]

This plus the change to use the build script

View changes since this review

[tgross35]

One other note is that you may want to consider doing something similar for fma once this lands, since that's used by many other operations.

[taiki-e]

It looks like you could also check for the fpregs without soft-float? I'm not sure whether that's more accurate. @taiki-e you may have some thoughts here.

 target_feature="fpregs"
-target_feature="soft-float"
 target_feature="thumb2"

Hmm. It's odd that fpregs,vfp2,vfp3,d32 are enabled for soft-float targets by default.

Given that they are enabled for armv7-unknown-linux-gnueabi and armv7a-none-eabi but not for arm-unknown-linux-gnueabi, armv7r-none-eabi, and thumbv7em-none-eabi, I guess LLVM infer that fregs are available for v7 + aclass.

[silverstillisntgold]

Spent some time looking into this yesterday and it's a weird situation. The eabihf ending specifically indicates that the target can pass fp32 (and maybe f64) values via registers, which means the target should have fp registers, which implies it should have an FPU (https://doc.rust-lang.org/rustc/platform-support/arm-none-eabi.html#instruction-sets). This is why the -fpregs flag is suggested as the means to disable the FPU on targets which support it by default. And LLVM seems to assume FPU's include a sqrt, so using all(target_arch = "arm", target_abi = "eabihf") should indeed be sufficient for detecting that a sqrt instruction supporting at least f32 is available.

The whole vfp* family is a chain of features each of which is a superset of those beneath it, and which are most often implied rather than being directly enabled. Thumbv8m uses +fp-armv8d16sp as a baseline, and you'll notice it ends with sp, which is f32. This implies vfp5sp, and all single precision version before it. Most of this seems to happen on the LLVM side, but some of it can be seen here.

You can see that something like Armv7a has the +vfp3d16 feature (no sp suffix). So it supports f64 (which implies f32) by default.

Doing a feature test for vfp2 is definitely the most convenient way to handle enabling a f64 variant, but arm features are currently unstable. Right now doing the f32 variant should be easy, but for f64 the only stable way I can think of is to match on specific target_cpu values (or even specific target triples) which are assumed by LLVM to have f64 support (M7, M55, M85, etc.). This approach would probably be super ugly.

I can finish up reworking the sqrtf feature gating, but I think a proper f64 sqrt implementation should probably be it's own PR. Might even be best to block it on the stabilization of arm features. Targets which have f64 tend to be more powerful than those with only f32 (f32 only are mostly embedded targets), so it could be argued that they benefit less from the hardware acceleration and can hold off just a bit longer with the current software implementation.

[silverstillisntgold]

It looks like you could also check for the fpregs without soft-float? I'm not sure whether that's more accurate. @taiki-e you may have some thoughts here.

 target_feature="fpregs"
-target_feature="soft-float"
 target_feature="thumb2"

Hmm. It's odd that fpregs,vfp2,vfp3,d32 are enabled for soft-float targets by default.

Given that they are enabled for armv7-unknown-linux-gnueabi and armv7a-none-eabi but not for arm-unknown-linux-gnueabi, armv7r-none-eabi, and thumbv7em-none-eabi, I guess LLVM infer that fregs are available for v7 + aclass.

My understanding is that the eabihf suffix only impacts the use of FP registers for passing values per this explanation. It seems to be for literally nothing more than to constrain the ABI. You can still use fp ops within your code and if you have features enabled that let you use hardware fp ops then LLVM should still emit them.

The Cortex-A7 lists FeatureVFP4, so it can use f64/f32 ops, just not in a way that shows up in the ABI.

[tgross35]

Spent some time looking into this yesterday and it's a weird situation. The eabihf ending specifically indicates that the target can pass fp32 (and maybe f64) values via registers, which means the target should have fp registers, which implies it should have an FPU (https://doc.rust-lang.org/rustc/platform-support/arm-none-eabi.html#instruction-sets). This is why the -fpregs flag is suggested as the means to disable the FPU on targets which support it by default.

My understanding is that eabihf implies two things:

1. The fpregs feature
2. We can actually use the FPU and clobber its state

So gating the module on all(target_arch = "arm", target_abi = "eabihf"), as it is now, makes sense.

And LLVM seems to assume FPU's include a sqrt, so using all(target_arch = "arm", target_abi = "eabihf") should indeed be sufficient for detecting that a sqrt instruction supporting at least f32 is available.

The problem is that fpregs doesn't imply vfp2 or vfp2sp on the Rust side https://github.com/rust-lang/rust/blob/d9dd0703ba332dbdd19ae6c9bf7ab98ab7c933c7/compiler/rustc_target/src/target_features.rs#L180 so we don't actually reject -Ctarget-feature=-vfp2,-vfp2sp2. LLVM currently crashes but the combination of vreg ABI with soft float math is theoretically possible, or we could get a new weird target that uses vregs but can't do vsqrt.f32 for some reason.

I assume that will be clarified as part of @adamgemmell's refactor (mentioned at rust-lang/rust#161826) but for the time being, I'd prefer to gate the individual function on any(target_feature = "vfp2", target_feature = "vfp2sp") to be on the safe side. It is unfortunate that this will only work with nightly, but we really can't do better until rust-lang/rust#150246 is stabilized. Or update target_features.rs to indicate that fpregs implies vfp2sp - but I don't know that's actually something we'd want to do.

I can finish up reworking the sqrtf feature gating, but I think a proper f64 sqrt implementation should probably be it's own PR. Might even be best to block it on the stabilization of arm features.

Up to you! I'm happy to take both together since they're pretty similar, with a #[cfg(any(target_feature = "vfp2", target_feature = "vfp2sp"))] gate for sqrtf and #[cfg(target_feature = "vfp2")] for sqrt, but it's also fine to split.

[silverstillisntgold]

If the only safe option is to use flags only available on nightly then it's probably best to delay this until arm_target_feature stabilizes. Since if a user is already on nightly they may as well use core_float_math or core_intrinsics, where LLVM already correctly handles any possible lowering and they can avoid pulling in another dependency.

[tgross35]

I think that's orthogonal, if you use libm and build with nightly you'll get these implementations without needing to do anything special or use #![feature] (i.e. your crate doesn't effectively become nightly-only). And arm_target_feature could very well stabilize first if Adam is working on it.

Even once core_float_math stabilizes, there will still be a number of crates that must continue to use libm to meet the MSRV.

[tgross35]

target_feature = “vfp2sp2” will be supported in the upcoming nightly, so that simplifies one of the issues.

[silverstillisntgold]

Seems like CARGO_CFG_TARGET_ABI isn't emitted by cargo in the MSRV version check 😢

[tgross35]

A handful of very small changes but with them, I think this should be all set. Could you please squash as well?

(the first commit message is outdated too, since sreg now works)

View changes since this review

[silverstillisntgold]

Remaining failures are due to ubuntu-26.04 benches using rustc 1.100.0-nightly (e71c0f1e3 2026-08-18), which doesn't have the vfp2sp feature.

[tgross35]

Remaining failures are due to ubuntu-26.04 benches using rustc 1.100.0-nightly (e71c0f1e3 2026-08-18), which doesn't have the vfp2sp feature.

Ah yeah I guess it's only old nightlies that don't work. Not the biggest deal as long as we don't break stable, but should be an easy fix once we get the syntax right.

[silverstillisntgold]

The problem is that fpregs doesn't imply vfp2 or vfp2sp on the Rust side https://github.com/rust-lang/rust/blob/d9dd0703ba332dbdd19ae6c9bf7ab98ab7c933c7/compiler/rustc_target/src/target_features.rs#L180 so we don't actually reject -Ctarget-feature=-vfp2,-vfp2sp2. LLVM currently crashes but the combination of vreg ABI with soft float math is theoretically possible, or we could get a new weird target that uses vregs but can't do vsqrt.f32 for some reason.

I assume that will be clarified as part of @adamgemmell's refactor (mentioned at rust-lang/rust#161826) but for the time being, I'd prefer to gate the individual function on any(target_feature = "vfp2", target_feature = "vfp2sp") to be on the safe side. It is unfortunate that this will only work with nightly, but we really can't do better until rust-lang/rust#150246 is stabilized. Or update target_features.rs to indicate that fpregs implies vfp2sp - but I don't know that's actually something we'd want to do.

Before this is merged I'd like to again try to make the case for treating eabihf as enough of a requirement for sqrtf. Yes, someone could pass -Ctarget-feature=-vfp2,-vfp2sp2, but those features are unstable and I doubt many people even know of their existence. I checked all 28 eabihf targets in stable's spec/targets and all of them support at least vfp2sp, either explicitly via their feature field or through their backend llvm_target representation. Most are vfp3, with the thumb targets mostly being vfp4sp with reduced register counts. Using -Ctarget-cpu is stable and can only add features to the target baseline, so no risk of specific CPU targets causing issues.

I'd argue that users explicitly opting to use the hard float ABI, then using unstable features to disable floating point operations just don't exist. Even though it's theoretically possible, it's a contradicting combination that's entirely impractical. And I can't foresee a world where a new target is added which somehow manages to reasonably combine these two opposing behaviors.

[tgross35]

My concern is still that the feature will be stable in the near future (hopefully!), and https://github.com/rust-lang/rust/blob/70222712809cd5cc1718ed8995914a1cbacb6b92/compiler/rustc_target/src/target_features.rs#L181 does not say fpregs implies vfp2sp. It's a one line change to make rustc promise that and I'd be happy to reflect it here once that happens, but until then it will be a valid, if niche, combination (once stable).

We can keep discussing because maybe there's an alternative (detect whether or not arm_target_feature is stable?), but I'd rather get this merged in its current state since it's so close. We can always relax things in the future.

[silverstillisntgold]

My concern is still that the feature will be stable in the near future (hopefully!), and https://github.com/rust-lang/rust/blob/70222712809cd5cc1718ed8995914a1cbacb6b92/compiler/rustc_target/src/target_features.rs#L181 does not say fpregs implies vfp2sp. It's a one line change to make rustc promise that and I'd be happy to reflect it here once that happens, but until then it will be a valid, if niche, combination (once stable).

We can keep discussing because maybe there's an alternative (detect whether or not arm_target_feature is stable?), but I'd rather get this merged in its current state since it's so close. We can always relax things in the future.

I don't think that fpregs will ever imply vfp2sp because vfp2sp now implies fpregs. I'm not sure how rustc handles circular dependencies in target features but there don't seem to be any others in target_features.rs so I'm guessing it's not functionality that's supported.

My argument is that even though the fpregs feature itself doesn't enable fp operations, use of an eabihf target is the user explicitly declaring they have a CPU/MCU which is known to have fp registers and an FPU (otherwise they'd use the equivalent soft-float eabi target), and so there's no reason to support them disabling fp ops provided by the FPU they've just knowingly opted in to (even though it's technically possible). And since all currently available (and likely any future released) arm/thumb targets which provide eabihf targets declare at minimum support for f32 regs/FPU, it's entirely reasonable to infer that all arm/thumb eabihf targets can safely call sqrtf. The f64 sqrt would still be gated on vfp2 either way since it's not a baseline across all arm/thumb targets.

If you'd still rather have both gated behind the features then I totally understand, and it's probably fine to merge for now, assuming it all looks good to you.

[adamgemmell]

Use of the vfp* features is what signifies the presence of an FPU, not use of a hf target. What does gating this on fpregs achieve, given that you say disabling vfp2sp won't happen in practice? It's also worth pointing out that removing a target_feature from a function in the future is not a breaking change, but adding it back is.

There's alternative implementations to a circular feature dependency - we could tie them together or fold them together under the same feature name, which have slightly different options available for splitting them post-stabilisation.

LLVM currently crashes but the combination of vreg ABI with soft float math is theoretically possible, or we could get a new weird target that uses vregs but can't do vsqrt.f32 for some reason.

Reading this suggests to me that we shouldn't expose fpregs at all (or leave it unstable) until that area can be worked out properly. That would bring it inline with aarch64 (and I think x86_64?) targets where the FPU and fp regs features are one.

I noticed the fact that FPU features are enabled on some a32 softfloat targets too and I think that's a mistake. I wouldn't use 32 bit arm target specs as an authoritative source on how something should work 😄

[silverstillisntgold]

Use of the vfp* features is what signifies the presence of an FPU, not use of a hf target. What does gating this on fpregs achieve, given that you say disabling vfp2sp won't happen in practice? It's also worth pointing out that removing a target_feature from a function in the future is not a breaking change, but adding it back is.

I'm advocating for gating the sqrtf implementation on the presence of the eabihf target ABI, not on the fpregs flag. Compiling for the hf ABI implies the user knows their target has some level of fp support, and all relevant targets support an f32 FPU as a baseline (they have at least vfp2sp enabled). From rustc's platform support:

"Rust targets ending in eabihf use the so-called hard-float ABI: functions which take f32 or f64 as arguments will have them passed via FPU registers. These targets therefore require the availability of an FPU and will assume some baseline level of floating-point support is available (which can vary depending on the target)."

There's alternative implementations to a circular feature dependency - we could tie them together or fold them together under the same feature name, which have slightly different options available for splitting them post-stabilisation.

LLVM currently crashes but the combination of vreg ABI with soft float math is theoretically possible, or we could get a new weird target that uses vregs but can't do vsqrt.f32 for some reason.

Reading this suggests to me that we shouldn't expose fpregs at all (or leave it unstable) until that area can be worked out properly. That would bring it inline with aarch64 (and I think x86_64?) targets where the FPU and fp regs features are one.

What's currently being proposed wouldn't require direct access to fpregs.

I noticed the fact that FPU features are enabled on some a32 softfloat targets too and I think that's a mistake. I wouldn't use 32 bit arm target specs as an authoritative source on how something should work 😄

Even though it's weird this may very well be intentional, from the same rustc platform support doc linked above:

"Rust targets ending with eabi use the so-called soft-float ABI: functions which take f32 or f64 as arguments will have those values packed into integer registers. This means that an FPU is not required from an ABI perspective, but within a function floating-point instructions may still be used if the code is compiled with a target-cpu or target-feature option that enables FPU support."

[adamgemmell]

Still agree with Trevor that vfp2sp is required: https://rust.godbolt.org/z/jfjx79adz (this error originates from LLVM). The feature can always be removed in the future

Even though it's weird this may very well be intentional, from the same rustc platform support doc linked above:

"Rust targets ending with eabi use the so-called soft-float ABI: functions which take f32 or f64 as arguments will have those values packed into integer registers. This means that an FPU is not required from an ABI perspective, but within a function floating-point instructions may still be used if the code is compiled with a target-cpu or target-feature option that enables FPU support."

Interesting, thanks for the link

[silverstillisntgold]

I also agree that vfp2sp is definitely a hard requirement. But because vfp2sp is enabled on all hf targets, I believe it's fine if the compilation argument combination you shared fails to compile. If a user wants to use a specific ABI without eabihf they should use the provided sf equivalent (which also fails in this example), instead of choosing a target which provides a set of features then immediately disabling those features.

[tgross35]

@adamgemmell how close do you think arm_target_feature is? In theory we could stabilize using vfp2sp and vfp2 in cfg but forbid toggling them, since they don't seem like the problematic part of rust-lang/rust#149512 (comment), which would make this issue go away.

If you'd still rather have both gated behind the features then I totally understand, and it's probably fine to merge for now, assuming it all looks good to you.

Yeah, I'd prefer to get this merged and we can figure something out in a followup. Just needs the two open things resolved to take care of warnings.

I guess one option is to have a list of current eabihf targets and manually set target_feature = "vfp2sp" or target_feature = "vfp2" if (1) the target is in that list, (2) there are no target_features, meaning it's running with a version prior to arm_target_feature being stabilized. (1) would prevent my concern about miscompiling with a future target that is eabihf but doesn't have the right instructions, if such a thing were ever to exist, and (2) would resolve the concern about users toggling vfp2sp off since there's no way to do that stably.

[tgross35]

Thanks for sticking this with, looks great to me!

If you're interested in following up to get this working on stable, I think a triple->features map as I mentioned in the previous comment would work.

View changes since this review

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[adamgemmell]

I'm scheduled to work on them next quarter, and I'd like to gather up and run the pros/cons by people before stabilising any features, in particular FPU features. Once set we've moved to stabilise the features relatively quickly in the past (a few months?). Is the motivation mainly unblocking using these functions on nightly?

[tgross35]

Oh right sorry, you did say that on the issue. For these specific features, having them stable would mean mean we get to use these and future asm ops without nightly—I was just weighing whether a workaround is worth it for now. Or, if other features are blocked on naming for the time being, whether there might be a subset we could stabilize sooner.

[adamgemmell]

The combinatorial explosion of fpu features might be a contention point, for example vfp2 can be modelled as vfp2sp + fp64 so we might not want to expose that. That might have knock-on effects for naming of the minimum feature levels like vfp2sp. For those reasons I'd prefer not to stabilise either for now.

[silverstillisntgold]

@tgross35 @adamgemmell Sorry to bring this back from the dead. Was researching the required feature levels for ARM32/Thumb fma and RISC-V sqrt/fma and found that version 1.97 stabilized CfgStableToggleUnstable, which is specifically for unstable features which can be used in #[cfg(x)] feature gating. The RISC-V team then used this to stabilize using d, e, and f extensions in cfg blocks in version 1.98 without fully stabilizing the features.

Is this something worth pursuing for the ARM features, ahead of full stabilization of arm_target_feature?

[silverstillisntgold]

@tgross35 @adamgemmell Sorry to bring this back from the dead. Was researching the required feature levels for ARM32/Thumb fma and RISC-V sqrt/fma and found that version 1.97 stabilized CfgStableToggleUnstable, which is specifically for unstable features which can be used in #[cfg(x)] feature gating. The RISC-V team then used this to stabilize using d, e, and f extensions in cfg blocks in version 1.98 without fully stabilizing the features.

Is this something worth pursuing for the ARM features, ahead of full stabilization of arm_target_feature?

The pull to stabilize d, e, and f was actually reverted, but only because of concerns around the e feature being a negative feature. The follow-up for stabilizing just d and f looks to be on track to make it into version 1.100, albeit using Stable instead of CfgStableToggleUnstable. Still, now that the functionality is in the compiler this might be a reasonable use for it.

[tgross35]

I think that, based on what Adam was saying, there's a chance that the names might not actually stay vfp2sp and vfp2 - in which case we wouldn't want to stabilize them in any form yet. Though that's a good option once the names are figured out, if we're not yet sure what should be toggleable.