[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250414121559.GS1827@brightrain.aerifal.cx>
Date: Mon, 14 Apr 2025 08:16:00 -0400
From: Rich Felker <dalias@...c.org>
To: Jesse DeGuire <jesse.a.deguire@...il.com>, musl@...ts.openwall.com
Subject: Re: [PATCH] Add additional __ARM_FP checks to ARM FPU math
functions
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?
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.
