[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-toolchain
Subject:    Re: [PATCH v2] ARM: Block predication on atomics [PR111235]
From:       Richard Earnshaw <Richard.Earnshaw () foss ! arm ! com>
Date:       2023-10-20 16:47:52
Message-ID: 3db1d221-5587-4942-80e7-a75f1b767713 () foss ! arm ! com
[Download RAW message or body]



On 02/10/2023 18:12, Wilco Dijkstra wrote:
> Hi Ramana,
> 
>>> I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
>>> --build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the
>>> default armhf settings are incorrect. I shouldn't need the --with-float=hard since
>>> that is obviously implied by armhf, and they should also imply armv7-a with vfpv3
>>> according to documentation. It seems to get confused and skip some tests. I tried
>>> using --with-fpu=auto, but that doesn't work at all, so in the end I forced it like:
>>> --with-arch=armv8-a --with-fpu=neon-fp-armv8. With this it runs a few more tests.
>>
>> Yeah that's a wart that I don't like.
>>
>> armhf just implies the hard float ABI and came into being to help
>> distinguish from the Base PCS for some of the distros at the time
>> (2010s). However we didn't want to set a baseline arch at that time
>> given the imminent arrival of v8-a and thus the specification of
>> --with-arch , --with-fpu and --with-float became second nature to many
>> of us working on it at that time.
> 
> Looking at it, the default is indeed incorrect, you get:
> '-mcpu=arm10e' '-mfloat-abi=hard' '-marm' '-march=armv5te+fp'
That's not incorrect.  It's the first version of the architecture that 
can support the hard-float ABI.

> 
> That's like 25 years out of date!

It's not a matter of being out of date (and it's only 22 years since 
arm1020e was announced ;) it's a matter of being as compatible as we can 
be with existing hardware out-of-the-box.  Distros are free, of course, 
to set a higher bar and do so.

> 
> However all the armhf distros have Armv7-a as the baseline and use Thumb-2:
> '-mfloat-abi=hard' '-mthumb' '-march=armv7-a+fp'

Wrong.  Rawhide uses Arm state (or it did last I checked).  As I 
mentioned above, distros are free to set a higher bar.

> 
> So the issue is that dg-require-effective-target arm_arch_v7a_ok doesn't work on
> armhf. It seems that if you specify an architecture even with hard-float configured,
> it turns off FP and then complains because hard-float implies you must have FP...

OK, I think I see the problem there, it's in the data for
         proc add_options_for_arm_arch_FUNC

in lib/target-supports.exp.  In order to work correctly with -mfpu=auto, 
the -march flags in the table need "+fp" adding in most cases (pretty 
much everything from armv5e onwards) - that's harmless whenever the 
float-abi is soft, but should do the right thing when softfp or hard are 
used.

> 
> So in most configurations Iincluding the one used by distro compilers) we basically
> skip lots of tests for no apparent reason...
> 
>> Ok, thanks for promising to do so - I trust you to get it done. Please
>> try out various combinations of -march v7ve, v7-a , v8-a with the tool
>> as each of them have slightly different rules. For instance v7ve
>> allows LDREXD and STREXD to be single copy atomic for 64 bit loads
>> whereas v7-a did not .
> 
> You mean LDRD may be generated on CPUs with LPAE. We use LDREXD by
> default since that is always atomic on v7-a.
> 
>> Ok if no regressions but as you might get nagged by the post commit CI ...
> 
> Thanks, I've committed it. Those links don't show anything concrete, however I do note
> the CI didn't pick up v2.
> 
> Btw you're happy with backports if there are no issues reported for a few days?
> 
> Cheers,
> Wilco

R.
_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
[prev in list] [next in list] [prev in thread] [next in thread]