[PATCH 00/31] aarch64: Add SME2 support

[Richard Sandiford]

Jan Beulich <jbeulich@suse.com> writes:
> On 03.04.2023 10:27, Richard Sandiford wrote:
>> Jan Beulich <jbeulich@suse.com> writes:
>>> On 03.04.2023 10:05, Richard Sandiford wrote:
>>>> Jan Beulich <jbeulich@suse.com> writes:
>>>>> On 30.03.2023 12:26, Richard Sandiford via Binutils wrote:
>>>>>> Richard Sandiford (31):
>>>>>>   aarch64: Add +sme2
>>>>>>   aarch64: Add a _10 suffix to FLD_imm3
>>>>>>   aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array
>>>>>>   aarch64: Add support for vgx2 and vgx4
>>>>>>   aarch64; Add support for vector offset ranges
>>>>>>   aarch64: Add support for predicate-as-counter registers
>>>>>>   aarch64: Add the SME2 MOVA instructions
>>>>>>   aarch64: Add the SME2 multivector LD1 and ST1 instructions
>>>>>
>>>>> Less than a 3rd of the patches in this series have made it to my mailbox
>>>>> (and the list archives), so commenting on e.g. the one above is difficult.
>>>>
>>>> Yeah, they got held up in moderation due to the size.
>>>>
>>>>> Nevertheless - according to the documentation LD1x (scalar plus immediate,
>>>>> consecutive registers) and their LDNT1x, ST1x, and STNT1x counterparts
>>>>> are (unlike the strided forms) SVE2.1 insns, not SME2 ones (IOW it looks
>>>>> as if the use of SME2_INSN() there is wrong, unless the documentation is
>>>>> categorizing these incorrectly).
>>>>
>>>> They're both (but we haven't added SVE2p1 to binutils yet).
>>>> E.g. see the pseudocode in:
>>>>
>>>>   https://developer.arm.com/documentation/ddi0602/2022-12/SVE-Instructions/LD1B--scalar-plus-immediate--consecutive-registers---Contiguous-load-of-bytes-to-multiple-consecutive-vectors--immediate-index--?lang=en
>>>>
>>>> where the condition is:
>>>>
>>>>   if !HaveSME2() && !HaveSVE2p1() then UNDEFINED;
>>>>
>>>> Chronologically, SME2 predates SVE2p1.
>>>
>>> Yet aiui dependency-wise, like SVE2 is a prereq to SME, SVE2.1 is going
>>> to be viewed as a prereq to SVE2.1?
>> 
>> Do you mean SVE2p1 being a prereq to SME2?  If so, no.  FEAT_SME2
>> && !FEAT_SVE2p1 is a valid combination, and in that case, these
>> instructions will only be available in streaming mode.  The way the
>> pseudo expresses this is:
>> 
>>   if HaveSVE2p1() then CheckSVEEnabled(); else CheckStreamingSVEEnabled();
>
> That's different from the SME <-> SVE2 relationship then? Or is that
> dependency wrong in tc-aarch64.c:aarch64_features[]?

Yeah, it's a different relationship from SME <-> SVE2.  For one thing,
SVE2p1 includes things that SME2 doesn't, such as:

  https://developer.arm.com/documentation/ddi0602/2022-12/SVE-Instructions/ADDQV--Unsigned-add-reduction-of-quadword-vector-segments-?lang=en

FEAT_SME && !FEAT_SVE is architecturally valid, but we took the decision
not to support it for tools.  The rule that +sme implies +sve2 is therefore
a software requirement rather than an ISA requirement.

Thanks,
Richard