This patch models SME features by adding features for the different PSTATE.SM
and PSTATE.ZA states, and implementing these as independent features to SME,
SVE(2) and NEON. This approach comes from the observation that setting
PSTATE.SM=1 invalidates instructions that are only valid when PSTATE.SM=0.
The same holds for setting PSTATE.SM=0, which invalidates SME instructions.
It can therefore be considered a subtractive feature, rather than an additive
feature.
This patch adds the following:
- +pstate-sm0 is set by default for all subtargets. NEON/SVE/SVE2 instructions that are only valid when PSTATE.SM=0 are predicated with HasPSTATESM0. In contrast to runtime, for the compiler it is allowed to have both +pstate-sm0 and +pstate-sm1 set, as this makes both instructions available to the compiler. It is up to the compiler (or compiler-user in case of inline-asm) to guarantee that PSTATE.SM is sufficiently guarded/honoured.
- +pstate-sm1 is enabled by default and enables all instructions valid under PSTATE.SM=1.
- +pstate-za1 is enabled by default and enables all instructions valid under PSTATE.ZA=1.
- +sme, +sme-i64 and +sme-f64 are the (only) user-visible flags to enable SME support.
The set of streaming-compatible NEON/SVE/SVE2 instructions are neither
predicated on HasPSTATESM0 nor HasPSTATESM1, and can therefore be
expressed with e.g. -mattr=+sve2,-pstate-sm0[,-pstate-sm1].
The set of streaming-agnostic SME instructions are not predicated on
HasPSTATESM1 and can be expressed with -mattr=+sme,-pstate-sm1.
This is an alternative approach as proposed in D120261 that follows from
an offline conversation with @rsandifo-arm.
I think from the user's perspective these flags are now normal unqualified "Enable ..” features, i.e. simple “is this feature present?” flags. The modality is applied on top.