* [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
@ 2023-11-16 15:19 Tamar Christina
2023-11-20 12:52 ` Richard Earnshaw
0 siblings, 1 reply; 7+ messages in thread
From: Tamar Christina @ 2023-11-16 15:19 UTC (permalink / raw)
To: gcc-patches
Cc: nd, Richard.Earnshaw, Marcus.Shawcroft, Kyrylo.Tkachov,
richard.sandiford
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
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.
--
[-- Attachment #2: rb18013.patch --]
[-- Type: text/plain, Size: 1631 bytes --]
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-16 15:19 [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64 Tamar Christina
@ 2023-11-20 12:52 ` Richard Earnshaw
2023-11-20 21:49 ` Tamar Christina
0 siblings, 1 reply; 7+ messages in thread
From: Richard Earnshaw @ 2023-11-20 12:52 UTC (permalink / raw)
To: Tamar Christina, gcc-patches
Cc: nd, Richard.Earnshaw, Marcus.Shawcroft, Kyrylo.Tkachov,
richard.sandiford
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-20 12:52 ` Richard Earnshaw
@ 2023-11-20 21:49 ` Tamar Christina
2023-11-21 9:38 ` Richard Earnshaw
0 siblings, 1 reply; 7+ messages in thread
From: Tamar Christina @ 2023-11-20 21:49 UTC (permalink / raw)
To: Richard Earnshaw, gcc-patches
Cc: nd, Richard Earnshaw, Marcus Shawcroft, Kyrylo Tkachov,
Richard Sandiford
> -----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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-20 21:49 ` Tamar Christina
@ 2023-11-21 9:38 ` Richard Earnshaw
2023-11-21 9:41 ` Richard Biener
2023-11-21 9:45 ` Tamar Christina
0 siblings, 2 replies; 7+ messages in thread
From: Richard Earnshaw @ 2023-11-21 9:38 UTC (permalink / raw)
To: Tamar Christina, gcc-patches
Cc: nd, Richard Earnshaw, Marcus Shawcroft, Kyrylo Tkachov,
Richard Sandiford
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-21 9:38 ` Richard Earnshaw
@ 2023-11-21 9:41 ` Richard Biener
2023-11-21 9:48 ` Tamar Christina
2023-11-21 9:45 ` Tamar Christina
1 sibling, 1 reply; 7+ messages in thread
From: Richard Biener @ 2023-11-21 9:41 UTC (permalink / raw)
To: Richard Earnshaw
Cc: Tamar Christina, gcc-patches, nd, Richard Earnshaw,
Marcus Shawcroft, Kyrylo Tkachov, Richard Sandiford
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-21 9:38 ` Richard Earnshaw
2023-11-21 9:41 ` Richard Biener
@ 2023-11-21 9:45 ` Tamar Christina
1 sibling, 0 replies; 7+ messages in thread
From: Tamar Christina @ 2023-11-21 9:45 UTC (permalink / raw)
To: Richard Earnshaw, gcc-patches
Cc: nd, Richard Earnshaw, Marcus Shawcroft, Kyrylo Tkachov,
Richard Sandiford
>
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64
2023-11-21 9:41 ` Richard Biener
@ 2023-11-21 9:48 ` Tamar Christina
0 siblings, 0 replies; 7+ messages in thread
From: Tamar Christina @ 2023-11-21 9:48 UTC (permalink / raw)
To: Richard Biener, Richard Earnshaw
Cc: gcc-patches, nd, Richard Earnshaw, Marcus Shawcroft,
Kyrylo Tkachov, Richard Sandiford
> -----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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-11-21 9:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-16 15:19 [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64 Tamar Christina
2023-11-20 12:52 ` Richard Earnshaw
2023-11-20 21:49 ` Tamar Christina
2023-11-21 9:38 ` Richard Earnshaw
2023-11-21 9:41 ` Richard Biener
2023-11-21 9:48 ` Tamar Christina
2023-11-21 9:45 ` Tamar Christina
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).