[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250414221712.GC288056@port70.net>
Date: Tue, 15 Apr 2025 00:17:12 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: Jesse DeGuire <jesse.a.deguire@...il.com>, musl@...ts.openwall.com
Subject: Re: [PATCH] Add additional __ARM_FP checks to ARM FPU math
functions
* Rich Felker <dalias@...c.org> [2025-04-14 16:51:34 -0400]:
> On Mon, Apr 14, 2025 at 04:32:28PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@...c.org> [2025-04-14 08:16:00 -0400]:
> >
> > > On Mon, Apr 14, 2025 at 12:30:56PM +0200, Szabolcs Nagy wrote:
> > > > * Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
