> -----Original Message----- > From: Richard Biener <richard.guent...@gmail.com> > Sent: Tuesday, November 21, 2023 9:41 AM > To: Richard Earnshaw <richard.earns...@foss.arm.com> > Cc: Tamar Christina <tamar.christ...@arm.com>; gcc-patches@gcc.gnu.org; > nd <n...@arm.com>; Richard Earnshaw <richard.earns...@arm.com>; > Marcus Shawcroft <marcus.shawcr...@arm.com>; Kyrylo Tkachov > <kyrylo.tkac...@arm.com>; Richard Sandiford > <richard.sandif...@arm.com> > Subject: Re: [PATCH]AArch64 docs: update -mcpu=generic definition on > aarch64 > > On Tue, Nov 21, 2023 at 10:3 AM Richard Earnshaw > <richard.earns...@foss.arm.com> wrote: > > > > > > > > On 20/11/2023 21:49, Tamar Christina wrote: > > >> -----Original Message----- > > >> From: Richard Earnshaw <richard.earns...@foss.arm.com> > > >> Sent: Monday, November 20, 2023 12:53 PM > > >> To: Tamar Christina <tamar.christ...@arm.com>; > > >> gcc-patches@gcc.gnu.org > > >> Cc: nd <n...@arm.com>; Richard Earnshaw > <richard.earns...@arm.com>; > > >> Marcus Shawcroft <marcus.shawcr...@arm.com>; Kyrylo Tkachov > > >> <kyrylo.tkac...@arm.com>; Richard Sandiford > > >> <richard.sandif...@arm.com> > > >> Subject: Re: [PATCH]AArch64 docs: update -mcpu=generic definition > > >> on > > >> aarch64 > > >> > > >> > > >> > > >> On 16/11/2023 15:19, Tamar Christina wrote: > > >> > Hi All, > > >> > > > >> > This documents the behavior of the generic CPU options on AArch64. > > >> > > > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > >> > > > >> > Ok for master? > > >> > > > >> > Thanks, > > >> > Tamar > > >> > > > >> > gcc/ChangeLog: > > >> > > > >> > * doc/invoke.texi (generic): Update defintion. > > >> > (generic-armv8-a, generic-armv9-a): Document. > > >> > > > >> > --- inline copy of patch -- > > >> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index > > >> > > > >> > d0b55fb106f908e8222394bbd07670aa583c5680..77684c5d7c9c0bdd5872 > > >> 50acc190 > > >> > da81e0f7f032 100644 > > >> > --- a/gcc/doc/invoke.texi > > >> > +++ b/gcc/doc/invoke.texi > > >> > @@ -20759,7 +20759,8 @@ processors implementing the target > > >> architecture. > > >> > @item -mtune=@var{name} > > >> > Specify the name of the target processor for which GCC should tune > the > > >> > performance of the code. Permissible values for this option are: > > >> > -@samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, > > >> > @samp{cortex-a55}, > > >> > +@samp{generic}, @samp{generic-armv8-a}, @samp{generic-armv9- > a}, > > >> > +@samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55}, > > >> > @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, > > >> @samp{cortex-a75}, > > >> > @samp{cortex-a76}, @samp{cortex-a76ae}, @samp{cortex-a77}, > > >> > @samp{cortex-a65}, @samp{cortex-a65ae}, @samp{cortex-a34}, @@ > > >> > -20798,6 +20799,11 @@ arithmetic instructions per cycle (2 for > > >> > 256-bit > > >> SVE, 4 for 128-bit SVE). > > >> > This is more general than tuning for a specific core like Neoverse V1 > > >> > but is more specific than the default tuning described below. > > >> > > > >> > +The value @samp{generic} should not be assumed to be a static > > >> configuration. > > >> > +Starting with GCC 14 this value can change over time in order to > > >> > +better reflect advancements in CPU microarchitecture. If a > > >> > +specific version is required you are encouraged to use one of > > >> > +the architecture > > >> specific generic processors, e.g. @samp{generic-armv8-a}. > > >> > + > > >> > Additionally on native AArch64 GNU/Linux systems the value > > >> > @samp{native} tunes performance to the host system. This > > >> > option has no > > >> effect > > >> > if the compiler is unable to recognize the processor of the host > > >> > system. > > >> > > > >> > > > >> > > > >> > > > >> @opindex mcpu > > >> @item -mcpu=@var{name} > > >> Specify the name of the target processor, optionally suffixed by > > >> one or more feature modifiers. This option has the form @option{- > > >> mcpu=@var{cpu}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}, where > the > > >> permissible values for @var{cpu} are the same as those available > > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> ^ > > >> for @option{-mtune}. > > >> ^^^^^^^^^^^^^^^^^^^^ > > >> > > >> So what is the behaviour now if these are used for -mcpu? Do we > > >> really want to permit their use here? > > >> > > > > > > They behave as any other CPU but with the baseline architecture and > > > no extensions i.e. -mcpu=generic == -march=armv8-a -mtune=generic. > > > > > > We've never blocked them before so doing so now would be a regression. > > > Conceptually they do make sense as -mcpu values as they just mean > > > "give me the best compatibility with this architecture as a baseline". > > > > My point is that if 'generic' can change meaning from release to > > release (which is acceptable for tune), then it becomes somewhat > > ambiguous (and therefore useless) for a CPU. > > Which is why x86 doesn't have -march=generic but only -mtune=generic. > IMHO options selecting ISA features shouldn't change their meaning over > time. >
Agreed, and that's not the plan. Perhaps this was unclear. Today generic Generates code for lowest baseline architecture but tuned for a 10 year old core. The intention of this clarification is to say that the target being tuned for will change in the future. Not the architecture being selected. Tamar > > R.