[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250414143228.GA290567@port70.net>
Date: Mon, 14 Apr 2025 16:32:28 +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 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 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.
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.
