public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Carlotti <andrew.carlotti@arm.com>
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford <richard.sandiford@arm.com>
Subject: [PATCH 00/12] aarch64: Extend aarch64_feature_flags to 128 bits
Date: Tue, 14 May 2024 15:54:32 +0100	[thread overview]
Message-ID: <0c99ec88-434d-a9de-0e0e-c281cb2dff4d@e124511.cambridge.arm.com> (raw)

The end goal of the series is to change the definition of aarch64_feature_flags
from a uint64_t typedef to a class with 128 bits of storage.  This class uses
operator overloading to mimic the existing integer interface as much as
possible, but with added restrictions to facilate type checking and
extensibility.

Patches 01-10 are preliminary enablement work, and have passed regression
testing.  Are these ok for master?

Patch 11 is an RFC, and the only patch that touches the middle end.  I am
seeking clarity on which part(s) of the compiler should be expected to handle
or prevent non-bool types in instruction pattern conditions.  The actual patch
does not compile by itself (though it does in combination with 12/12), but that
is not important to the questions I'm asking.

Patch 12 is then a small patch that actually replaces the uint64_t typedef with
a class.  I think this patch is fine in it's current form, but it depends on a
resolution to the issues in patch 11/12 first.

             reply	other threads:[~2024-05-14 14:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-14 14:54 Andrew Carlotti [this message]
2024-05-14 14:55 ` [PATCH 01/12] aarch64: Remove unused global aarch64_tune_flags Andrew Carlotti
2024-05-14 14:55 ` [PATCH 02/12] aarch64: Move AARCH64_NUM_ISA_MODES definition Andrew Carlotti
2024-05-14 14:56 ` [PATCH 03/12] aarch64: Don't use 0 for aarch64_feature_flags Andrew Carlotti
2024-05-14 14:56 ` [PATCH 04/12] aarch64: Don't compare aarch64_feature_flags to 0 Andrew Carlotti
2024-05-14 14:56 ` [PATCH 05/12] aarch64: Eliminate a temporary variable Andrew Carlotti
2024-05-14 14:57 ` [PATCH 06/12] aarch64: Introduce aarch64_isa_mode type Andrew Carlotti
2024-05-14 14:57 ` [PATCH 07/12] aarch64: Define aarch64_get_{asm_|}isa_flags Andrew Carlotti
2024-05-14 14:58 ` [PATCH 08/12] aarch64: Decouple feature flag option storage type Andrew Carlotti
2024-05-14 14:58 ` [PATCH 09/12] aarch64: Assign flags to local constexpr variable Andrew Carlotti
2024-05-14 14:59 ` [PATCH 10/12] aarch64: Add aarch64_feature_flags_from_index macro Andrew Carlotti
2024-05-14 14:59 ` [RFC 11/12] Add explicit bool casts to .md condition users Andrew Carlotti
2024-05-14 15:00 ` [PATCH 12/12] aarch64: Extend aarch64_feature_flags to 128 bits Andrew Carlotti
2024-05-17 15:45 ` [PATCH 00/12] " Richard Sandiford
2024-05-20 12:09   ` Andrew Carlotti
2024-05-20 15:53     ` Richard Sandiford

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=0c99ec88-434d-a9de-0e0e-c281cb2dff4d@e124511.cambridge.arm.com \
    --to=andrew.carlotti@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@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).