[musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Jesse DeGuire]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Hi everyone!

I found that I was getting compiler errors when I try to build Musl
for an ARMv8.1M Mainline target that does not have floating-point
support but does have the M-Profile Vector Extensions (MVE). The
errors were that Musl wanted to use unsupported floating-point
instructions for fabsf() and sqrtf().

I was able to correct this by adding checks for (__ARM_FP & 4) to the
ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.

The relevant options I used with Clang were "-march=armv8.1m.main+mve
-mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
treats them as 8 128-bit registers instead of 16 64-bit registers, so
presumably that's why the hard float ABI is used even when
floating-point operations are not enabled. In this case, an
integer-only subset of MVE is used.

Here is a Godbolt link that shows that you can make this happen on GCC, too.
https://www.godbolt.org/z/Mf4h489s8

I'm not sure if this is totally necessary since I suspect this would
affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
to have.

Thanks,
Jesse DeGuire

[-- Attachment #2: arm_fp_check.patch --]
[-- Type: application/octet-stream, Size: 664 bytes --]

diff --git a/src/math/arm/fabsf.c b/src/math/arm/fabsf.c
index 4a217c98..790d4cfe 100644
--- a/src/math/arm/fabsf.c
+++ b/src/math/arm/fabsf.c
@@ -1,6 +1,6 @@
 #include <math.h>
 
-#if __ARM_PCS_VFP && !BROKEN_VFP_ASM
+#if __ARM_PCS_VFP && !BROKEN_VFP_ASM && (__ARM_FP&4)
 
 float fabsf(float x)
 {
diff --git a/src/math/arm/sqrtf.c b/src/math/arm/sqrtf.c
index 32693293..51f44f8c 100644
--- a/src/math/arm/sqrtf.c
+++ b/src/math/arm/sqrtf.c
@@ -1,6 +1,6 @@
 #include <math.h>
 
-#if (__ARM_PCS_VFP || (__VFP_FP__ && !__SOFTFP__)) && !BROKEN_VFP_ASM
+#if (__ARM_PCS_VFP || (__VFP_FP__ && !__SOFTFP__)) && !BROKEN_VFP_ASM && (__ARM_FP&4)
 
 float sqrtf(float x)
 {

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Rich Felker]

On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> Hi everyone!
> 
> I found that I was getting compiler errors when I try to build Musl
> for an ARMv8.1M Mainline target that does not have floating-point
> support but does have the M-Profile Vector Extensions (MVE). The
> errors were that Musl wanted to use unsupported floating-point
> instructions for fabsf() and sqrtf().
> 
> I was able to correct this by adding checks for (__ARM_FP & 4) to the
> ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> 
> The relevant options I used with Clang were "-march=armv8.1m.main+mve
> -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> treats them as 8 128-bit registers instead of 16 64-bit registers, so
> presumably that's why the hard float ABI is used even when
> floating-point operations are not enabled. In this case, an
> integer-only subset of MVE is used.
> 
> Here is a Godbolt link that shows that you can make this happen on GCC, too.
> https://www.godbolt.org/z/Mf4h489s8
> 
> I'm not sure if this is totally necessary since I suspect this would
> affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> to have.

I'm looking over this now and based on the ARM docs it sounds like
it's correct. Can anyone else confirm?

It also looks like it matches how we check for hardware double support
in other files.

Rich

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2025-02-21 19:25:00 -0500]:

> On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> > Hi everyone!
> > 
> > I found that I was getting compiler errors when I try to build Musl
> > for an ARMv8.1M Mainline target that does not have floating-point
> > support but does have the M-Profile Vector Extensions (MVE). The
> > errors were that Musl wanted to use unsupported floating-point
> > instructions for fabsf() and sqrtf().
> > 
> > I was able to correct this by adding checks for (__ARM_FP & 4) to the
> > ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> > 
> > The relevant options I used with Clang were "-march=armv8.1m.main+mve
> > -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> > treats them as 8 128-bit registers instead of 16 64-bit registers, so
> > presumably that's why the hard float ABI is used even when
> > floating-point operations are not enabled. In this case, an
> > integer-only subset of MVE is used.
> > 
> > Here is a Godbolt link that shows that you can make this happen on GCC, too.
> > https://www.godbolt.org/z/Mf4h489s8
> > 
> > I'm not sure if this is totally necessary since I suspect this would
> > affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> > to have.
> 
> I'm looking over this now and based on the ARM docs it sounds like
> it's correct. Can anyone else confirm?
> 
> It also looks like it matches how we check for hardware double support
> in other files.

looks good.

but i'd expect this to affect fenv too. i don't see
separate acle macro for that so i'd use (__ARM_FP & 12)
i.e if there is no double or single prec hw then there
is no hw fenv.

i'm not sure if there is a need to check for vfp call
abi. do we want nop fenv on softfp arm? i'd expect
the call abi to not matter if we allow fp hw instns.

i guess the fenv fix can be a separate patch.

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Rich Felker]

On Mon, Apr 14, 2025 at 12:30:56PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2025-02-21 19:25:00 -0500]:
> 
> > On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> > > Hi everyone!
> > > 
> > > I found that I was getting compiler errors when I try to build Musl
> > > for an ARMv8.1M Mainline target that does not have floating-point
> > > support but does have the M-Profile Vector Extensions (MVE). The
> > > errors were that Musl wanted to use unsupported floating-point
> > > instructions for fabsf() and sqrtf().
> > > 
> > > I was able to correct this by adding checks for (__ARM_FP & 4) to the
> > > ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> > > 
> > > The relevant options I used with Clang were "-march=armv8.1m.main+mve
> > > -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> > > treats them as 8 128-bit registers instead of 16 64-bit registers, so
> > > presumably that's why the hard float ABI is used even when
> > > floating-point operations are not enabled. In this case, an
> > > integer-only subset of MVE is used.
> > > 
> > > Here is a Godbolt link that shows that you can make this happen on GCC, too.
> > > https://www.godbolt.org/z/Mf4h489s8
> > > 
> > > I'm not sure if this is totally necessary since I suspect this would
> > > affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> > > to have.
> > 
> > I'm looking over this now and based on the ARM docs it sounds like
> > it's correct. Can anyone else confirm?
> > 
> > It also looks like it matches how we check for hardware double support
> > in other files.
> 
> looks good.
> 
> but i'd expect this to affect fenv too. i don't see
> separate acle macro for that so i'd use (__ARM_FP & 12)
> i.e if there is no double or single prec hw then there
> is no hw fenv.
> 
> i'm not sure if there is a need to check for vfp call
> abi. do we want nop fenv on softfp arm? i'd expect
> the call abi to not matter if we allow fp hw instns.
> 
> i guess the fenv fix can be a separate patch.

fenv is conditional on hardfloat ABI, not presence of floating point
instructions. Am I missing something here for why it also affect this?

Rich

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2025-04-14 08:16:00 -0400]:

> On Mon, Apr 14, 2025 at 12:30:56PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2025-02-21 19:25:00 -0500]:
> > 
> > > On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> > > > Hi everyone!
> > > > 
> > > > I found that I was getting compiler errors when I try to build Musl
> > > > for an ARMv8.1M Mainline target that does not have floating-point
> > > > support but does have the M-Profile Vector Extensions (MVE). The
> > > > errors were that Musl wanted to use unsupported floating-point
> > > > instructions for fabsf() and sqrtf().
> > > > 
> > > > I was able to correct this by adding checks for (__ARM_FP & 4) to the
> > > > ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> > > > 
> > > > The relevant options I used with Clang were "-march=armv8.1m.main+mve
> > > > -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> > > > treats them as 8 128-bit registers instead of 16 64-bit registers, so
> > > > presumably that's why the hard float ABI is used even when
> > > > floating-point operations are not enabled. In this case, an
> > > > integer-only subset of MVE is used.
> > > > 
> > > > Here is a Godbolt link that shows that you can make this happen on GCC, too.
> > > > https://www.godbolt.org/z/Mf4h489s8
> > > > 
> > > > I'm not sure if this is totally necessary since I suspect this would
> > > > affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> > > > to have.
> > > 
> > > I'm looking over this now and based on the ARM docs it sounds like
> > > it's correct. Can anyone else confirm?
> > > 
> > > It also looks like it matches how we check for hardware double support
> > > in other files.
> > 
> > looks good.
> > 
> > but i'd expect this to affect fenv too. i don't see
> > separate acle macro for that so i'd use (__ARM_FP & 12)
> > i.e if there is no double or single prec hw then there
> > is no hw fenv.
> > 
> > i'm not sure if there is a need to check for vfp call
> > abi. do we want nop fenv on softfp arm? i'd expect
> > the call abi to not matter if we allow fp hw instns.
> > 
> > i guess the fenv fix can be a separate patch.
> 
> fenv is conditional on hardfloat ABI, not presence of floating point
> instructions. Am I missing something here for why it also affect this?

i don't understand your question.

__ARM_PCS_VFP is defined (hf abi), but there is no hw
fenv (fpscr reg) so fenv-hf.S compilation fails imho.

we didnt think of "hf abi but no hw fp support" before.

i don't know if these changes are enough to support
the v8.1-m target since it has mve simd regs that
may need additional code for save/restore at runtime,
but the changes should not hurt.

i was also wondering if hw fenv might make sense with
soft float abi.

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Rich Felker]

On Mon, Apr 14, 2025 at 04:32:28PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2025-04-14 08:16:00 -0400]:
> 
> > On Mon, Apr 14, 2025 at 12:30:56PM +0200, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@libc.org> [2025-02-21 19:25:00 -0500]:
> > > 
> > > > On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> > > > > Hi everyone!
> > > > > 
> > > > > I found that I was getting compiler errors when I try to build Musl
> > > > > for an ARMv8.1M Mainline target that does not have floating-point
> > > > > support but does have the M-Profile Vector Extensions (MVE). The
> > > > > errors were that Musl wanted to use unsupported floating-point
> > > > > instructions for fabsf() and sqrtf().
> > > > > 
> > > > > I was able to correct this by adding checks for (__ARM_FP & 4) to the
> > > > > ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> > > > > 
> > > > > The relevant options I used with Clang were "-march=armv8.1m.main+mve
> > > > > -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> > > > > treats them as 8 128-bit registers instead of 16 64-bit registers, so
> > > > > presumably that's why the hard float ABI is used even when
> > > > > floating-point operations are not enabled. In this case, an
> > > > > integer-only subset of MVE is used.
> > > > > 
> > > > > Here is a Godbolt link that shows that you can make this happen on GCC, too.
> > > > > https://www.godbolt.org/z/Mf4h489s8
> > > > > 
> > > > > I'm not sure if this is totally necessary since I suspect this would
> > > > > affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> > > > > to have.
> > > > 
> > > > I'm looking over this now and based on the ARM docs it sounds like
> > > > it's correct. Can anyone else confirm?
> > > > 
> > > > It also looks like it matches how we check for hardware double support
> > > > in other files.
> > > 
> > > looks good.
> > > 
> > > but i'd expect this to affect fenv too. i don't see
> > > separate acle macro for that so i'd use (__ARM_FP & 12)
> > > i.e if there is no double or single prec hw then there
> > > is no hw fenv.
> > > 
> > > i'm not sure if there is a need to check for vfp call
> > > abi. do we want nop fenv on softfp arm? i'd expect
> > > the call abi to not matter if we allow fp hw instns.
> > > 
> > > i guess the fenv fix can be a separate patch.
> > 
> > fenv is conditional on hardfloat ABI, not presence of floating point
> > instructions. Am I missing something here for why it also affect this?
> 
> i don't understand your question.
> 
> __ARM_PCS_VFP is defined (hf abi), but there is no hw
> fenv (fpscr reg) so fenv-hf.S compilation fails imho.
> 
> we didnt think of "hf abi but no hw fp support" before.

I didn't understand the topic at hand as "hf abi but no hw fp
support", rather "hf abi but only single precision hw fp support".
This still should have fenv.

> i don't know if these changes are enough to support
> the v8.1-m target since it has mve simd regs that
> may need additional code for save/restore at runtime,
> but the changes should not hurt.
> 
> i was also wondering if hw fenv might make sense with
> soft float abi.

I think long ago we had a question of whether softfloat ABI targets
that might conditionally have hardware with fenv support or
conditionally have software/emulated fenv should be defining the fenv
macros, but allowing the fenv functions to return failure. That was
never really resolved. But unless this is an important kind of target,
it's kinda complexity I'd rather not get into, and probably not very
nice to applications either, which might expect fenv to just work if
it's there..

Rich

Re: [musl] [PATCH] Add additional __ARM_FP checks to ARM FPU math functions

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2025-04-14 16:51:34 -0400]:

> On Mon, Apr 14, 2025 at 04:32:28PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2025-04-14 08:16:00 -0400]:
> > 
> > > On Mon, Apr 14, 2025 at 12:30:56PM +0200, Szabolcs Nagy wrote:
> > > > * Rich Felker <dalias@libc.org> [2025-02-21 19:25:00 -0500]:
> > > > 
> > > > > On Wed, Nov 20, 2024 at 08:26:23PM -0600, Jesse DeGuire wrote:
> > > > > > Hi everyone!
> > > > > > 
> > > > > > I found that I was getting compiler errors when I try to build Musl
> > > > > > for an ARMv8.1M Mainline target that does not have floating-point
> > > > > > support but does have the M-Profile Vector Extensions (MVE). The
> > > > > > errors were that Musl wanted to use unsupported floating-point
> > > > > > instructions for fabsf() and sqrtf().
> > > > > > 
> > > > > > I was able to correct this by adding checks for (__ARM_FP & 4) to the
> > > > > > ARM "fabsf.c" and "sqrtf.c" files, which is all this tiny patch does.
> > > > > > 
> > > > > > The relevant options I used with Clang were "-march=armv8.1m.main+mve
> > > > > > -mfpu=none -mfloat-abi=hard". MVE uses the FP register file, but
> > > > > > treats them as 8 128-bit registers instead of 16 64-bit registers, so
> > > > > > presumably that's why the hard float ABI is used even when
> > > > > > floating-point operations are not enabled. In this case, an
> > > > > > integer-only subset of MVE is used.
> > > > > > 
> > > > > > Here is a Godbolt link that shows that you can make this happen on GCC, too.
> > > > > > https://www.godbolt.org/z/Mf4h489s8
> > > > > > 
> > > > > > I'm not sure if this is totally necessary since I suspect this would
> > > > > > affect only ARM M-Profile devices, but maybe it at least wouldn't hurt
> > > > > > to have.
> > > > > 
> > > > > I'm looking over this now and based on the ARM docs it sounds like
> > > > > it's correct. Can anyone else confirm?
> > > > > 
> > > > > It also looks like it matches how we check for hardware double support
> > > > > in other files.
> > > > 
> > > > looks good.
> > > > 
> > > > but i'd expect this to affect fenv too. i don't see
> > > > separate acle macro for that so i'd use (__ARM_FP & 12)
> > > > i.e if there is no double or single prec hw then there
> > > > is no hw fenv.
> > > > 
> > > > i'm not sure if there is a need to check for vfp call
> > > > abi. do we want nop fenv on softfp arm? i'd expect
> > > > the call abi to not matter if we allow fp hw instns.
> > > > 
> > > > i guess the fenv fix can be a separate patch.
> > > 
> > > fenv is conditional on hardfloat ABI, not presence of floating point
> > > instructions. Am I missing something here for why it also affect this?
> > 
> > i don't understand your question.
> > 
> > __ARM_PCS_VFP is defined (hf abi), but there is no hw
> > fenv (fpscr reg) so fenv-hf.S compilation fails imho.
> > 
> > we didnt think of "hf abi but no hw fp support" before.
> 
> I didn't understand the topic at hand as "hf abi but no hw fp
> support", rather "hf abi but only single precision hw fp support".
> This still should have fenv.

it is hf abi, but with no single precision hw fp ops,
nor hw fenv. only hw fp register file and load/store ops.

https://www.godbolt.org/z/hanc3qxT4

so we need to check __ARM_FP in asm code to avoid using
hw fp ops there.

setjmp runtime code maybe wrong depending on how the kernel
sets hwcap for this weird target.

> 
> > i don't know if these changes are enough to support
> > the v8.1-m target since it has mve simd regs that
> > may need additional code for save/restore at runtime,
> > but the changes should not hurt.
> > 
> > i was also wondering if hw fenv might make sense with
> > soft float abi.
> 
> I think long ago we had a question of whether softfloat ABI targets
> that might conditionally have hardware with fenv support or
> conditionally have software/emulated fenv should be defining the fenv
> macros, but allowing the fenv functions to return failure. That was
> never really resolved. But unless this is an important kind of target,
> it's kinda complexity I'd rather not get into, and probably not very
> nice to applications either, which might expect fenv to just work if
> it's there..
> 
> Rich