From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Tamar Christina <Tamar.Christina@arm.com>,
"gcc-patches@gcc.gnu.org" <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
Date: Tue, 21 Nov 2023 09:38:30 +0000 [thread overview]
Message-ID: <bb64ba64-0c59-430f-9c5e-81afa0dfaadb@foss.arm.com> (raw)
In-Reply-To: <VI1PR08MB5325B97294BF72A463628357FFB4A@VI1PR08MB5325.eurprd08.prod.outlook.com>
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.
next prev parent reply other threads:[~2023-11-21 9:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 15:19 Tamar Christina
2023-11-20 12:52 ` Richard Earnshaw
2023-11-20 21:49 ` Tamar Christina
2023-11-21 9:38 ` Richard Earnshaw [this message]
2023-11-21 9:41 ` Richard Biener
2023-11-21 9:48 ` Tamar Christina
2023-11-21 9:45 ` Tamar Christina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb64ba64-0c59-430f-9c5e-81afa0dfaadb@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=Kyrylo.Tkachov@arm.com \
--cc=Marcus.Shawcroft@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Richard.Sandiford@arm.com \
--cc=Tamar.Christina@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).