>
> 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.
>
But I don't think we should be moving the baseline architecture for generic,
only
the tuning part.
For moving your baseline we have the more specific ones like
-mcpu=generic-armv9-a
for instance.
So the meaning of generic should stay the same, widest compatible binaries with
good
but not the best performance.
Perhaps I should clarify that.
Cheers,
Tamar
> R.
