@@ -67,57 +67,42 @@ enum CPUFeatures {
FEAT_FP,
FEAT_SIMD,
FEAT_CRC,
- FEAT_SHA1,
FEAT_SHA2,
FEAT_SHA3,
FEAT_AES,
- FEAT_PMULL,
FEAT_FP16,
- FEAT_DIT,
FEAT_DPB,
FEAT_DPB2,
FEAT_JSCVT,
FEAT_FCMA,
FEAT_RCPC,
FEAT_RCPC2,
FEAT_FRINTTS,
- F
@@ -73,8 +73,6 @@ enum CPUFeatures {
FEAT_SSBS,
FEAT_SSBS2,
FEAT_BTI,
- FEAT_LS64,
- FEAT_LS64_V,
andrewcarlotti wrote:
I think we might need to keep the enum values stable, although I'm not sure
whether this could actually cause any issues yet.
(c.f.
andrewcarlotti wrote:
> However the architecture does not mandate that both need to be implemented at
> the same time.
This premise is incorrect. For FEAT_SVE_AES and FEAT_SVE_PMULL128, the latest
version of the Arm ARM (DDI 0487K.a) includes the following in the definition
of `ID_AA64ZFR0_E
@@ -33,7 +33,6 @@ enum CPUFeatures {
FEAT_FP,
FEAT_SIMD,
FEAT_CRC,
- FEAT_SHA1,
andrewcarlotti wrote:
> And the clang and gcc implementations of FMV are already ABI incompatible for
> other reasons.
Are they? I'm not currently aware of any incompatibil
andrewcarlotti wrote:
I think the existing situation before FMV was already a bit confusing.
We have the command line feature `+memtag`. This enables all the instructions
specified in FEAT_MTE and FEAT_MTE2. Note that the FEAT_MTE2 instructions
aren't available at EL0.
With `-mcpu=neoverse-v2
andrewcarlotti wrote:
> > Suppose you have target_version("i8mm+dotprod") and target_version("fcma").
> > The first version clearly has higher priority
>
> According to the [current
> rules](https://arm-software.github.io/acle/main/acle.html#selection) yes, but
> IMO that rule is broken and
