your patches enabling Arm64's SVE 2.1 extension

your patches enabling Arm64's SVE 2.1 extension

[Jan Beulich]

Srinath,

may I ask against what specification these were written? There are many
aspects I can't bring in line with what DDI0596 from December has, i.e.
even newer than the patch (dating back to October), to a degree that I
have to even question gas/NEWS stating (supposedly complete) support for
the feature:

1) dupq uses encodings different from the doc, in part resulting in
   supposedly reserved encodings (tsz=0).

2) extq uses syntax (operands) pretty different from what the doc says.

3) ld1q and st1q expect a plain first register operand, not one enclosed
   in figure braces.

4) ld2q, ld3q, ld4q, st2q, st3q, and st4q don't permit a wrapping
   sequence of vector registers, when the doc using "modulo" imo can't be
   read any way other than meaning to permit that.

5) ld2q's scalar plus scalar encoding has bits 13 and 14 set, which is
   inconsistent not only with the doc, but also with ld3q and ld4q.

6) ld3q/st3q and ld4q/st4q scalar plus immediate forms demand an immediate
   that's a multiple of 2, when the doc says 3 and 4 respectively.

7) orqv, pmov, tblq, tbxq, uzpq{1,2}, and zipq{1,2} are entirely missing.

Despite being newer it's of course possible that documentation is what
actually needs fixing. Can you please clarify which way it is?

Thanks, Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Srinath Parvathaneni]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

Hi Jan,

On 2/12/2024 8:00 AM, Jan Beulich wrote:
> Srinath,
>
> may I ask against what specification these were written? There are many
> aspects I can't bring in line with what DDI0596 from December has, i.e.
> even newer than the patch (dating back to October), to a degree that I
> have to even question gas/NEWS stating (supposedly complete) support for
> the feature:
>
> 1) dupq uses encodings different from the doc, in part resulting in
>     supposedly reserved encodings (tsz=0).
>
> 2) extq uses syntax (operands) pretty different from what the doc says.
>
> 3) ld1q and st1q expect a plain first register operand, not one enclosed
>     in figure braces.
>
> 4) ld2q, ld3q, ld4q, st2q, st3q, and st4q don't permit a wrapping
>     sequence of vector registers, when the doc using "modulo" imo can't be
>     read any way other than meaning to permit that.
>
> 5) ld2q's scalar plus scalar encoding has bits 13 and 14 set, which is
>     inconsistent not only with the doc, but also with ld3q and ld4q.
>
> 6) ld3q/st3q and ld4q/st4q scalar plus immediate forms demand an immediate
>     that's a multiple of 2, when the doc says 3 and 4 respectively.

Thanks for the email and posting the issues with the sve2p1 
instructions. I have

checked the above mentioned instructions against the latest specs, the

documentation is correct and the issues are from the posted patches

(needs further tests as well). I will create a bugzilla (if it isn't 
created already)

ticket for all the mentioned instructions and work on fixing those issues.

> 7) orqv, pmov, tblq, tbxq, uzpq{1,2}, and zipq{1,2} are entirely missing.

I'm aware the above mentioned instructions are missing in binutils and 
I'm currently

working on adding support for these instructions. I will update you once 
the patches

are committed.

Regards,

Srinath

> Despite being newer it's of course possible that documentation is what
> actually needs fixing. Can you please clarify which way it is?
>
> Thanks, Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Jan Beulich]

On 13.02.2024 00:16, Srinath Parvathaneni wrote:
> On 2/12/2024 8:00 AM, Jan Beulich wrote:
>> 7) orqv, pmov, tblq, tbxq, uzpq{1,2}, and zipq{1,2} are entirely missing.
> 
> I'm aware the above mentioned instructions are missing in binutils and 
> I'm currently
> 
> working on adding support for these instructions. I will update you once 
> the patches
> 
> are committed.

In which case - what is the gas/NEWS entry about? Just in case there would
be a 2.42.1, may I ask that it be purged at least there, and perhaps also
from the main branch, until support is actually complete? Alternatively,
Nick, once support is complete maybe that's then really a(nother) reason
to cut a 2.42.1?

Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Nick Clifton]

Hi Jan, Hi Srinath,
> In which case - what is the gas/NEWS entry about? Just in case there would
> be a 2.42.1, may I ask that it be purged at least there, and perhaps also
> from the main branch, until support is actually complete?

I would agree with this.

> Alternatively,
> Nick, once support is complete maybe that's then really a(nother) reason
> to cut a 2.42.1?

Hmmm... this is a hard decision.  Normally I would only consider a point release
if we needed to fix an important bug - one which could result in incorrect code
generation or total failure of a tool like the linker or assembler.  But a release
just to add some missing instructions which were supposed to be supported but were
actually not ... well that does not seem to me to be a good enough reason.

Unless - how significant are these instructions ?  I have not actually looked
into their semantics.  Are there needed in order for a kernel to be able to
access specific features of the AArch64 architecture ?  Are they essential for
atomic operations ?  Are they even likely to be produced by a compiler ?

Basically if they are not critical to the infrastructure of an operating system,
then I do not think that they justify a point release.

Cheers
   Nick

Re: your patches enabling Arm64's SVE 2.1 extension

[Jan Beulich]

On 13.02.2024 10:55, Nick Clifton wrote:
> Hi Jan, Hi Srinath,
>> In which case - what is the gas/NEWS entry about? Just in case there would
>> be a 2.42.1, may I ask that it be purged at least there, and perhaps also
>> from the main branch, until support is actually complete?
> 
> I would agree with this.
> 
>> Alternatively,
>> Nick, once support is complete maybe that's then really a(nother) reason
>> to cut a 2.42.1?
> 
> Hmmm... this is a hard decision.  Normally I would only consider a point release
> if we needed to fix an important bug - one which could result in incorrect code
> generation or total failure of a tool like the linker or assembler.  But a release
> just to add some missing instructions which were supposed to be supported but were
> actually not ... well that does not seem to me to be a good enough reason.

Well, the missing insns were merely one out of 7 issues I found (so far,
plus the one or two further issues with GCS, and I didn't get to SME 2.1
yet). Other issues were indeed including wrong encodings being emitted.

> Unless - how significant are these instructions ?  I have not actually looked
> into their semantics.  Are there needed in order for a kernel to be able to
> access specific features of the AArch64 architecture ?  Are they essential for
> atomic operations ?  Are they even likely to be produced by a compiler ?

No atomics, no. But pretty certainly expected to be emitted by a compiler.
For a kernel, GCS is likely of more interest than SVE.

And no, I don't mean to strictly push for an eventual dot release. I
merely wanted to put up the question.

Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Nick Clifton]

Hi Jan,

> And no, I don't mean to strictly push for an eventual dot release. I
> merely wanted to put up the question.

That's fair.  I did have another, slightly self-serving idea.  How about,
once these issues are resolved, you make a point release ?  I have tried
to document the process in the README-how-to-make-a-release file in the
binutils directory and it would be great if there was someone besides
myself who was able to make these releases.  Plus, since I am probably
the only person who has ever read the file, it would be good to get some
feedback on its contents and accuracy...

No pressure though.  If you do not want to, or do not have the time, that
is OK.  I am just putting the idea out there.

Cheers
   Nick

Re: your patches enabling Arm64's SVE 2.1 extension

[Jan Beulich]

On 13.02.2024 12:11, Nick Clifton wrote:
>> And no, I don't mean to strictly push for an eventual dot release. I
>> merely wanted to put up the question.
> 
> That's fair.  I did have another, slightly self-serving idea.  How about,
> once these issues are resolved, you make a point release ?  I have tried
> to document the process in the README-how-to-make-a-release file in the
> binutils directory and it would be great if there was someone besides
> myself who was able to make these releases.  Plus, since I am probably
> the only person who has ever read the file, it would be good to get some
> feedback on its contents and accuracy...
> 
> No pressure though.  If you do not want to, or do not have the time, that
> is OK.  I am just putting the idea out there.

Let me at least coarsely look over that file, one of these days, and then
come back. Time is the limiting factor, and after reading I may have an
understanding towards that (plus perhaps some questions up front).

Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Jan Beulich]

On 13.02.2024 12:11, Nick Clifton wrote:
>> And no, I don't mean to strictly push for an eventual dot release. I
>> merely wanted to put up the question.
> 
> That's fair.  I did have another, slightly self-serving idea.  How about,
> once these issues are resolved, you make a point release ?  I have tried
> to document the process in the README-how-to-make-a-release file in the
> binutils directory and it would be great if there was someone besides
> myself who was able to make these releases.  Plus, since I am probably
> the only person who has ever read the file, it would be good to get some
> feedback on its contents and accuracy...
> 
> No pressure though.  If you do not want to, or do not have the time, that
> is OK.  I am just putting the idea out there.

Having replied to the Arm64 patch for the branch, I realize I still owe you
a reply here: I managed to read through a fair part of the document, and I
fear I found a number of steps that I wouldn't even be sure how to properly
arrange for (e.g. requiring specific utility versions, aiui). Which in
summary means that the effort needed would quite likely exceed what I could
afford.

I'm sorry, Jan

Re: your patches enabling Arm64's SVE 2.1 extension

[Andrew Carlotti]

On Tue, Feb 13, 2024 at 08:24:14AM +0100, Jan Beulich wrote:
> On 13.02.2024 00:16, Srinath Parvathaneni wrote:
> > On 2/12/2024 8:00 AM, Jan Beulich wrote:
> >> 7) orqv, pmov, tblq, tbxq, uzpq{1,2}, and zipq{1,2} are entirely missing.
> > 
> > I'm aware the above mentioned instructions are missing in binutils and 
> > I'm currently
> > 
> > working on adding support for these instructions. I will update you once 
> > the patches
> > 
> > are committed.
> 
> In which case - what is the gas/NEWS entry about?

I added the gas/NEWS entry because my expectation was that we wouldn't have
added only partial support for the extension (at least not without clearly
marking it as such).  I wasn't aware of any issues with our SVE 2.1 support
until after the 2.42 release; otherwise I would have modified gas/NEWS and
suggested disabling the flag until the next release.

> Just in case there would
> be a 2.42.1, may I ask that it be purged at least there, and perhaps also
> from the main branch, until support is actually complete? Alternatively,
> Nick, once support is complete maybe that's then really a(nother) reason
> to cut a 2.42.1?
> 
> Jan