| Message ID | patch-18013-tamar@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | AArch64 docs: update -mcpu=generic definition on aarch64 | expand |
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..77684c5d7c9c0bdd587250acc190da81e0f7f032 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? R.
> -----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". Regards, Tamar > R.
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. R.
On Tue, Nov 21, 2023 at 10:38 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. > R.
> > 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. > 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.
> -----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.
--- 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.
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..77684c5d7c9c0bdd587250acc190da81e0f7f032 100644 -- diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index d0b55fb106f908e8222394bbd07670aa583c5680..77684c5d7c9c0bdd587250acc190da81e0f7f032 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.