![]() |
|
Message-ID: <20250414205133.GT1827@brightrain.aerifal.cx> Date: Mon, 14 Apr 2025 16:51:34 -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 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. > 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.