public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tamar Christina <Tamar.Christina@arm.com>
To: Kyrylo Tkachov <ktkachov@nvidia.com>
Cc: "gcc-patches@gcc.gnu.org" <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
Date: Thu, 27 Jun 2024 14:58:36 +0000	[thread overview]
Message-ID: <VI1PR08MB5325F3BB2A7DB4D5B3DB6BC4FFD72@VI1PR08MB5325.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <13A94A06-2C37-42D0-8C30-BAD511DE40DA@nvidia.com>

> -----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
> >


  reply	other threads:[~2024-06-27 14:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27  8:58 Kyrylo Tkachov
2024-06-27 14:19 ` Tamar Christina
2024-06-27 14:48   ` Kyrylo Tkachov
2024-06-27 14:58     ` Tamar Christina [this message]
2024-06-28  7:41       ` Kyrylo Tkachov

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=VI1PR08MB5325F3BB2A7DB4D5B3DB6BC4FFD72@VI1PR08MB5325.eurprd08.prod.outlook.com \
    --to=tamar.christina@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ktkachov@nvidia.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).