Hi JangNing (please reply inline in the future as that is the preferred style on this mailing list)
> -----Original Message----- > From: JiangNing OS <jiangn...@os.amperecomputing.com> > Sent: 01 May 2020 11:49 > To: Richard Earnshaw <richard.earns...@foss.arm.com>; Kyrylo Tkachov > <kyrylo.tkac...@arm.com>; Andrew Pinski <pins...@gmail.com>; Florian > Weimer <fwei...@redhat.com> > Cc: gcc-patches@gcc.gnu.org; nmeye...@amzn.com > Subject: RE: Should ARMv8-A generic tuning default to -moutline-atomics > > In reality, a lot of users are still using old gcc versions running on new > hardware. OpenJDK is a typical example, I think. Although this option is not an ABI change and thus I don't expect it to break anything by design, it is definitely good to be cautious as it is a significant change in code generation. Let's wait for a few weeks to make sure the default change in GCC 10.1 works for everyone and then revisit the backport story. In any case, GCC 9 and 8 are not extremely close to release currently IIUC. Thanks, Kyrill > > > -----Original Message----- > > From: Richard Earnshaw <richard.earns...@foss.arm.com> > > Sent: Friday, May 1, 2020 6:41 PM > > To: JiangNing OS <jiangn...@os.amperecomputing.com>; Kyrylo Tkachov > > <kyrylo.tkac...@arm.com>; Andrew Pinski <pins...@gmail.com>; Florian > > Weimer <fwei...@redhat.com> > > Cc: gcc-patches@gcc.gnu.org; nmeye...@amzn.com > > Subject: Re: Should ARMv8-A generic tuning default to -moutline-atomics > > > > On 01/05/2020 11:38, JiangNing OS via Gcc-patches wrote: > > > Hi Kyrill, > > > > > > Can it be backported to gcc 8/9/10 branches? > > > > > > > I'm not sure changing the defaults of things like this is a good idea on > > 'dot' > > releases. > > > > Having the option is one thing. Changing the default another thing > > entirely. > > > > R. > > > > > Thanks, > > > -Jiangning > > > > > >> -----Original Message----- > > >> From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of > > >> Kyrylo Tkachov > > >> Sent: Thursday, April 30, 2020 8:27 PM > > >> To: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Andrew Pinski > > >> <pins...@gmail.com>; Florian Weimer <fwei...@redhat.com> > > >> Cc: gcc-patches@gcc.gnu.org; nmeye...@amzn.com > > >> Subject: RE: Should ARMv8-A generic tuning default to > > >> -moutline-atomics > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of > > >>> Kyrylo Tkachov > > >>> Sent: 30 April 2020 11:57 > > >>> To: Andrew Pinski <pins...@gmail.com>; Florian Weimer > > >>> <fwei...@redhat.com> > > >>> Cc: gcc-patches@gcc.gnu.org; nmeye...@amzn.com > > >>> Subject: RE: Should ARMv8-A generic tuning default to > > >>> -moutline-atomics > > >>> > > >>> [Moving to gcc-patches] > > >>> > > >>>> -----Original Message----- > > >>>> From: Gcc <gcc-boun...@gcc.gnu.org> On Behalf Of Andrew Pinski > via > > >>>> Gcc > > >>>> Sent: 30 April 2020 07:21 > > >>>> To: Florian Weimer <fwei...@redhat.com> > > >>>> Cc: GCC Mailing List <g...@gcc.gnu.org>; nmeye...@amzn.com > > >>>> Subject: Re: Should ARMv8-A generic tuning default to > > >>>> -moutline-atomics > > >>>> > > >>>> On Wed, Apr 29, 2020 at 6:25 AM Florian Weimer via Gcc > > >>>> <g...@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.tkac...@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.tkac...@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 > > >> > > >> Thanks, > > >> Kyrill
