Hi Kyrill, Can it be backported to gcc 8/9/10 branches?
Thanks, -Jiangning > -----Original Message----- > From: Gcc-patches <[email protected]> On Behalf Of Kyrylo > Tkachov > Sent: Thursday, April 30, 2020 8:27 PM > To: Kyrylo Tkachov <[email protected]>; Andrew Pinski > <[email protected]>; Florian Weimer <[email protected]> > Cc: [email protected]; [email protected] > Subject: RE: Should ARMv8-A generic tuning default to -moutline-atomics > > > > > -----Original Message----- > > From: Gcc-patches <[email protected]> On Behalf Of > > Kyrylo Tkachov > > Sent: 30 April 2020 11:57 > > To: Andrew Pinski <[email protected]>; Florian Weimer > > <[email protected]> > > Cc: [email protected]; [email protected] > > Subject: RE: Should ARMv8-A generic tuning default to > > -moutline-atomics > > > > [Moving to gcc-patches] > > > > > -----Original Message----- > > > From: Gcc <[email protected]> On Behalf Of Andrew Pinski via > > > Gcc > > > Sent: 30 April 2020 07:21 > > > To: Florian Weimer <[email protected]> > > > Cc: GCC Mailing List <[email protected]>; [email protected] > > > Subject: Re: Should ARMv8-A generic tuning default to > > > -moutline-atomics > > > > > > On Wed, Apr 29, 2020 at 6:25 AM Florian Weimer via Gcc > > > <[email protected]> > > > 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 <[email protected]> > > > > * 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 <[email protected]> > > > > * 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 > > Thanks, > Kyrill
