[PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[Kyrylo Tkachov]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Hi all,

According to the TRM for Neoverse V2 the Memory Tagging and RNG features
are optional configurations of the core and may not always be present.
Therefore -mcpu=neoverse-v2 shouldn't enable them, similar to how the crypto extensions aren’t enabled by default.

Bootstrapped and tested on aarch64-none-linux-gnu.
Does this reasoning make sense?
Thanks,
Kyrill


[-- Attachment #2: v2-remove-mte-rng.patch --]
[-- Type: application/octet-stream, Size: 2107 bytes --]

From 690b500ef2bb5b84eb09ed9841b3e3c033715103 Mon Sep 17 00:00:00 2001
From: Kyrylo Tkachov <ktkachov@nvidia.com>
Date: Sun, 23 Jun 2024 11:01:41 -0700
Subject: [PATCH] [aarch64] Remove RNG and MTE from -mcpu=neoverse-v2

According to the TRM for Neoverse V2 the Memory Tagging and RNG features
are optional configurations of the core and may not always be present.
Therefore -mcpu=neoverse-v2 shouldn't enable them.

Bootstrapped and tested on aarch64-none-linux-gnu

	* config/aarch64/aarch64-cores.def (neoverse-v2): Remove MEMTAG and
	RNG from features.
	(demeter): Likewise.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
---
 gcc/config/aarch64/aarch64-cores.def | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index e58bc0f27de..0c6150e407f 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -193,10 +193,10 @@ AARCH64_CORE("cortex-x4",  cortexx4, cortexa57, V9_2A,  (SVE2_BITPERM, MEMTAG, P
 AARCH64_CORE("neoverse-n2", neoversen2, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, RNG, MEMTAG, PROFILE), neoversen2, 0x41, 0xd49, -1)
 AARCH64_CORE("cobalt-100",   cobalt100, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, RNG, MEMTAG, PROFILE), neoversen2, 0x6d, 0xd49, -1)
 
-AARCH64_CORE("neoverse-v2", neoversev2, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, RNG, MEMTAG, PROFILE), neoversev2, 0x41, 0xd4f, -1)
+AARCH64_CORE("neoverse-v2", neoversev2, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, PROFILE), neoversev2, 0x41, 0xd4f, -1)
 AARCH64_CORE("grace", grace, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, SVE2_AES, SVE2_SHA3, SVE2_SM4, PROFILE), neoversev2, 0x41, 0xd4f, -1)
 
-AARCH64_CORE("demeter", demeter, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, RNG, MEMTAG, PROFILE), neoversev2, 0x41, 0xd4f, -1)
+AARCH64_CORE("demeter", demeter, cortexa57, V9A, (I8MM, BF16, SVE2_BITPERM, PROFILE), neoversev2, 0x41, 0xd4f, -1)
 
 /* Generic Architecture Processors.  */
 AARCH64_CORE("generic",  generic, cortexa53, V8A,  (), generic, 0x0, 0x0, -1)
-- 
2.34.1

RE: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[Tamar Christina]

Hi Kyrill,

> -----Original Message-----
> From: Kyrylo Tkachov <ktkachov@nvidia.com>
> Sent: Thursday, June 27, 2024 9:58 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
> <Richard.Sandiford@arm.com>
> Subject: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2
> 
> Hi all,
> 
> According to the TRM for Neoverse V2 the Memory Tagging and RNG features
> are optional configurations of the core and may not always be present.
> Therefore -mcpu=neoverse-v2 shouldn't enable them, similar to how the crypto
> extensions aren’t enabled by default.

RNG is indeed optional, however Memory Tagging is not.  The table is a bit cryptic
but it distinguishes between three states: "supported", "supported using configurable
option" and "unsupported".

RNG is supported with configurable option, but MTE is "supported" (this wording seems to
be used for things that are mandatory.).  If you look in table 2-7 of the TRM it states
"The Neoverse-V2 core always implements MTE".

This can be confirmed by looking at the table A-204: ID_AA64PFR1_EL1 bit descriptions.
For MTE the register cannot be 0b000, i.e. even though MTE is architecturally optional,
it's not valid for a Neoverse-V2 core not to have MTE.

This means that the compiler should declare support for MTE as at the CPU level it's always
supported.

Kind Regards,
Tamar

> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> Does this reasoning make sense?
> Thanks,
> Kyrill

Re: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[Kyrylo Tkachov]

Hi Tamar,
Thanks for going through the docs here,

> On 27 Jun 2024, at 16:19, Tamar Christina <tamar.christina@arm.com> wrote:
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Kyrill,
> 
>> -----Original Message-----
>> From: Kyrylo Tkachov <ktkachov@nvidia.com>
>> Sent: Thursday, June 27, 2024 9:58 AM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
>> <Richard.Sandiford@arm.com>
>> Subject: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2
>> 
>> Hi all,
>> 
>> According to the TRM for Neoverse V2 the Memory Tagging and RNG features
>> are optional configurations of the core and may not always be present.
>> Therefore -mcpu=neoverse-v2 shouldn't enable them, similar to how the crypto
>> extensions aren’t enabled by default.
> 
> RNG is indeed optional, however Memory Tagging is not.  The table is a bit cryptic
> but it distinguishes between three states: "supported", "supported using configurable
> option" and "unsupported".
> 
> RNG is supported with configurable option, but MTE is "supported" (this wording seems to
> be used for things that are mandatory.).  If you look in table 2-7 of the TRM it states
> "The Neoverse-V2 core always implements MTE".
> 
> This can be confirmed by looking at the table A-204: ID_AA64PFR1_EL1 bit descriptions.
> For MTE the register cannot be 0b000, i.e. even though MTE is architecturally optional,
> it's not valid for a Neoverse-V2 core not to have MTE.
> 
> This means that the compiler should declare support for MTE as at the CPU level it's always
> supported.

Okay, I guess this is indeed venturing into the grey area of what the compiler can enable/use.
My reading of the situation is that the Neoverse V2 core indeed always supports MTE instructions like you properly point out.

However for MTE to actually have any use, the SoC/system needs to implement the tag storage in the memory system, and not all systems choose to do so. In that case the MTE functionality isn’t actually exposed to the user through the OS (through HWCAPS, /proc/cpuinfo) so it may as well not be present. Perhaps it’s not useful for users to expose the __ARM_FEATURE_MEMORY_TAGGING macro and the arm_acle.h intrinsics for it in that case.

I’m okay with leaving out the MTE disabling from this patch and just removing the RNG option for now.
Thanks,
Kyrill

> 
> Kind Regards,
> Tamar
> 
>> 
>> Bootstrapped and tested on aarch64-none-linux-gnu.
>> Does this reasoning make sense?
>> Thanks,
>> Kyrill
> 

RE: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[Tamar Christina]

> -----Original Message-----
> From: Kyrylo Tkachov <ktkachov@nvidia.com>
> Sent: Thursday, June 27, 2024 3:49 PM
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw <Richard.Earnshaw@arm.com>;
> Richard Sandiford <Richard.Sandiford@arm.com>
> Subject: Re: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2
> 
> Hi Tamar,
> Thanks for going through the docs here,
> 
> > On 27 Jun 2024, at 16:19, Tamar Christina <tamar.christina@arm.com> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Kyrill,
> >
> >> -----Original Message-----
> >> From: Kyrylo Tkachov <ktkachov@nvidia.com>
> >> Sent: Thursday, June 27, 2024 9:58 AM
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
> >> <Richard.Sandiford@arm.com>
> >> Subject: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2
> >>
> >> Hi all,
> >>
> >> According to the TRM for Neoverse V2 the Memory Tagging and RNG features
> >> are optional configurations of the core and may not always be present.
> >> Therefore -mcpu=neoverse-v2 shouldn't enable them, similar to how the crypto
> >> extensions aren’t enabled by default.
> >
> > RNG is indeed optional, however Memory Tagging is not.  The table is a bit cryptic
> > but it distinguishes between three states: "supported", "supported using
> configurable
> > option" and "unsupported".
> >
> > RNG is supported with configurable option, but MTE is "supported" (this
> wording seems to
> > be used for things that are mandatory.).  If you look in table 2-7 of the TRM it
> states
> > "The Neoverse-V2 core always implements MTE".
> >
> > This can be confirmed by looking at the table A-204: ID_AA64PFR1_EL1 bit
> descriptions.
> > For MTE the register cannot be 0b000, i.e. even though MTE is architecturally
> optional,
> > it's not valid for a Neoverse-V2 core not to have MTE.
> >
> > This means that the compiler should declare support for MTE as at the CPU level
> it's always
> > supported.
> 
> Okay, I guess this is indeed venturing into the grey area of what the compiler can
> enable/use.
> My reading of the situation is that the Neoverse V2 core indeed always supports
> MTE instructions like you properly point out.
> 
> However for MTE to actually have any use, the SoC/system needs to implement
> the tag storage in the memory system, and not all systems choose to do so. In that
> case the MTE functionality isn’t actually exposed to the user through the OS
> (through HWCAPS, /proc/cpuinfo) so it may as well not be present. Perhaps it’s
> not useful for users to expose the __ARM_FEATURE_MEMORY_TAGGING macro
> and the arm_acle.h intrinsics for it in that case.

Yes, but uses of MTE should normally check for the HWCAPS anyway, as MTE support
as you say is configurable.

However it's still not the compiler's job.  The user should be able to use the intrinsics
Because otherwise even if they check HWCAPS they wouldn't be able to use it if
they are on an implementation of Neoverse-V2 that has both the system and CPU
components implemented.

So I believe it's wrong to remove MTE from the compiler flags, as the compiler should be
concerned with code generation. And Neoverse-V2 will not fault on MTE instructions.

Regards,
Tamar

> 
> I’m okay with leaving out the MTE disabling from this patch and just removing the
> RNG option for now.
> Thanks,
> Kyrill
> 
> >
> > Kind Regards,
> > Tamar
> >
> >>
> >> Bootstrapped and tested on aarch64-none-linux-gnu.
> >> Does this reasoning make sense?
> >> Thanks,
> >> Kyrill
> >

Re: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

[Kyrylo Tkachov]

[-- Attachment #1: Type: text/plain, Size: 4544 bytes --]



On 27 Jun 2024, at 16:58, Tamar Christina <tamar.christina@arm.com> wrote:

External email: Use caution opening links or attachments


-----Original Message-----
From: Kyrylo Tkachov <ktkachov@nvidia.com<mailto:ktkachov@nvidia.com>>
Sent: Thursday, June 27, 2024 3:49 PM
To: Tamar Christina <Tamar.Christina@arm.com<mailto:Tamar.Christina@arm.com>>
Cc: gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>; Richard Earnshaw <Richard.Earnshaw@arm.com<mailto:Richard.Earnshaw@arm.com>>;
Richard Sandiford <Richard.Sandiford@arm.com<mailto:Richard.Sandiford@arm.com>>
Subject: Re: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

Hi Tamar,
Thanks for going through the docs here,

On 27 Jun 2024, at 16:19, Tamar Christina <tamar.christina@arm.com> wrote:

External email: Use caution opening links or attachments


Hi Kyrill,

-----Original Message-----
From: Kyrylo Tkachov <ktkachov@nvidia.com>
Sent: Thursday, June 27, 2024 9:58 AM
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
<Richard.Sandiford@arm.com>
Subject: [PATCH] aarch64: Remove RNG and MTE from -mcpu=neoverse-v2

Hi all,

According to the TRM for Neoverse V2 the Memory Tagging and RNG features
are optional configurations of the core and may not always be present.
Therefore -mcpu=neoverse-v2 shouldn't enable them, similar to how the crypto
extensions aren’t enabled by default.

RNG is indeed optional, however Memory Tagging is not.  The table is a bit cryptic
but it distinguishes between three states: "supported", "supported using
configurable
option" and "unsupported".

RNG is supported with configurable option, but MTE is "supported" (this
wording seems to
be used for things that are mandatory.).  If you look in table 2-7 of the TRM it
states
"The Neoverse-V2 core always implements MTE".

This can be confirmed by looking at the table A-204: ID_AA64PFR1_EL1 bit
descriptions.
For MTE the register cannot be 0b000, i.e. even though MTE is architecturally
optional,
it's not valid for a Neoverse-V2 core not to have MTE.

This means that the compiler should declare support for MTE as at the CPU level
it's always
supported.

Okay, I guess this is indeed venturing into the grey area of what the compiler can
enable/use.
My reading of the situation is that the Neoverse V2 core indeed always supports
MTE instructions like you properly point out.

However for MTE to actually have any use, the SoC/system needs to implement
the tag storage in the memory system, and not all systems choose to do so. In that
case the MTE functionality isn’t actually exposed to the user through the OS
(through HWCAPS, /proc/cpuinfo) so it may as well not be present. Perhaps it’s
not useful for users to expose the __ARM_FEATURE_MEMORY_TAGGING macro
and the arm_acle.h intrinsics for it in that case.

Yes, but uses of MTE should normally check for the HWCAPS anyway, as MTE support
as you say is configurable.

However it's still not the compiler's job.  The user should be able to use the intrinsics
Because otherwise even if they check HWCAPS they wouldn't be able to use it if
they are on an implementation of Neoverse-V2 that has both the system and CPU
components implemented.

So I believe it's wrong to remove MTE from the compiler flags, as the compiler should be
concerned with code generation. And Neoverse-V2 will not fault on MTE instructions.


Ok, that makes sense. I guess we could make a similar argument for RNG.
Some implementations may have it, some don’t. Since its only use from the compiler is through intrinsics that would have to be gated under a runtime HWCAP we should leave it in the CPU definition to allow users to write such code. I do think it’s unlikely that a user would be writing such generic code and compiling with an -mcpu=neoverse-v2 option. They’d be using an -march option with an explicit +memtag. But a user who wants to compile code that runs on every Neoverse V2 implementation would want to use -mcpu

For a concrete implementation of Neoverse V2 like Grace, we know definitely it won’t be there so we can leave it out of -mcpu=grace.

I’m dropping this patch then.

Thanks,
Kyrill


Regards,
Tamar


I’m okay with leaving out the MTE disabling from this patch and just removing the
RNG option for now.
Thanks,
Kyrill


Kind Regards,
Tamar


Bootstrapped and tested on aarch64-none-linux-gnu.
Does this reasoning make sense?
Thanks,
Kyrill