Should ARMv8-A generic tuning default to -moutline-atomics
Szabolcs Nagy
szabolcs.nagy@arm.com
Thu May 14 11:14:32 GMT 2020
The 04/30/2020 12:26, Kyrylo Tkachov wrote:
> > > From: Gcc <gcc-bounces@gcc.gnu.org> On Behalf Of Andrew Pinski via Gcc
> > > On Wed, Apr 29, 2020 at 6:25 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> > > wrote:
> > > > Distributions are receiving requests to build things with
> > > > -moutline-atomics:
> > > >
> > > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956418>
> > > >
> > > > Should this be reflected in the GCC upstream defaults for ARMv8-A
> > > > generic tuning? It does not make much sense to me if every distribution
> > > > has to overide these flags, either in their build system or by patching
> > > > GCC.
> > >
> > > At least we should make it a configure option.
> > > I do want the ability to default it for our (Marvell) toolchain for
> > > Linux (our bare metal toolchain will be defaulting to ARMv8.2-a
> > > anyways).
> >
> > After some internal discussions, I am open to having it on as a default.
> > Here are two versions. One has it as a tuning setting that CPUs can override,
> > the other just switches it on by default always unless overridden by -mno-
> > outline-atomics.
> > I slightly prefer the second one as it's cleaner and simpler, but happy to take
> > either.
> > Any preferences?
> > Thanks,
> > Kyrill
> >
> > ChangeLogs:
> >
> > 2020-04-30 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
> >
> > * config/aarch64/aarch64-tuning-flags.def (no_outline_atomics):
> > Declare.
> > * config/aarch64/aarch64.h (TARGET_OUTLINE_ATOMICS): Define.
> > * config/aarch64/aarch64.opt (moutline-atomics): Change to Int
> > variable.
> >
> > 2020-04-30 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
> >
> > * config/aarch64/aarch64.h (TARGET_OUTLINE_ATOMICS): Define.
> > * config/aarch64/aarch64.opt (moutline-atomics): Change to Int
> > variable.
> > * doc/invoke.texi (moutline-atomics): Document as on by default.
>
> I've pushed this second variant after bootstrap and testing on aarch64-none-linux-gnu.
> Compiled a simple atomic-using testcase with all relevant combinations of -moutline-atomics and LSE and no-LSE -march options.
> Before the results were (as expected):
> |-moutline-atomics | -mno-outline-atomics | <no outline-atomics option
> --------------------------------------------------------------------------------
> LSE | inline LSE | inline LSE | inline LSE
> no-LSE | outline | inline LDXR/STXR | inline LDX/STXR
>
>
> with this patch they are:
> -moutline-atomics | -mno-outline-atomics | <no outline-atomics option>
> --------------------------------------------------------------------------------
> LSE | inline LSE | inline LSE | inline LSE
> no-LSE | outline | inline LDXR/STXR | outline
note that this change affects all aarch64 targets not just *-gnu,
(baremetal, freebsd, musl,..), however on non-gnu targets the
initializer with __getauxval is missing so the outlined calls
always use baseline LDXR/STXR.
in a given elf module the libgcc initializer may not run first
(e.g. it runs after ifunc resolvers, other initializers or
signal handler) and different objects may be compiled with
different outline-atomics setting so the outlined calls must
be abi compatible with LDXR/STXR atomics (i.e. outlining is not
an atomics abi change).
so presumably non-gnu targets want to build gcc with outline
atomics turned off by default or want a mechanism to propagate
the lse hwcap to libgcc that works other than in glibc.
I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95129
More information about the Gcc-patches
mailing list