On 01/05/2020 12:01, Kyrylo Tkachov wrote: > 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.
Frankly, I don't think there is anything to consider. We should not change codegen for an existing release series unless there is a bug. It upsets users who expect stability in dot releases. There's an option that can be used to change the behaviour, and that's enough. R. > > 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 >
