RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64

[Tamar Christina <Tamar.Christina@arm.com>]

> -----Original Message-----
> From: Richard Biener <richard.guenther@gmail.com>
> Sent: Tuesday, November 21, 2023 9:41 AM
> To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
> Cc: Tamar Christina <Tamar.Christina@arm.com>; gcc-patches@gcc.gnu.org;
> nd <nd@arm.com>; Richard Earnshaw <Richard.Earnshaw@arm.com>;
> Marcus Shawcroft <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov
> <Kyrylo.Tkachov@arm.com>; Richard Sandiford
> <Richard.Sandiford@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.Earnshaw@foss.arm.com> wrote:
> >
> >
> >
> > On 20/11/2023 21:49, Tamar Christina wrote:
> > >> -----Original Message-----
> > >> From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
> > >> Sent: Monday, November 20, 2023 12:53 PM
> > >> To: Tamar Christina <Tamar.Christina@arm.com>;
> > >> gcc-patches@gcc.gnu.org
> > >> Cc: nd <nd@arm.com>; Richard Earnshaw
> <Richard.Earnshaw@arm.com>;
> > >> Marcus Shawcroft <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov
> > >> <Kyrylo.Tkachov@arm.com>; Richard Sandiford
> > >> <Richard.Sandiford@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.