[PATCH 00/31] aarch64: Add SME2 support

[Richard Sandiford]

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();

> In which case enabling SVE2.1 alone
> ought to be sufficient to use these insns? Which would mean all of these
> (there are quite a few more) would need touching again.

When SVE2p1 is added, we'll need to make these instructions available
whenever SVE2p1 or SME2 is enabled.  It didn't seem worth preempting that
by adding SVE2p1 stuff in this series, not least because it wouldn't be
testable.  But it should be a simple enough change.

Thanks,
Richard