mbox series

[0/6] Arm64: (mostly) SVE adjustments

Message ID 2dbdd49f-2302-4dbc-98ba-0bdaf3c4cad2@suse.com
Headers
Series Arm64: (mostly) SVE adjustments |

Message

Jan Beulich Feb. 23, 2024, 11:26 a.m. UTC 
  Some of the issues addressed here were pointed out before, but only
not overly involved ones of those (plus a couple of subsequent findings)
are taken care of. The rest is left to people more familiar with the
inner workings of the operand type machinery.

1: correct B16B16 indexed bf{mla,mls,mul}
2: check matching operands for predicated B16B16 insns
3: check tied operand specifier in aarch64-gen
4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate)
5: correct SVE2.1 ld2q (scalar plus scalar)
6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1

At least the last patch wants backporting to 2.42.

Jan

Comments

Andrew Carlotti March 15, 2024, 4:20 p.m. UTC | #1 
On Fri, Feb 23, 2024 at 12:26:37PM +0100, Jan Beulich wrote:
> Some of the issues addressed here were pointed out before, but only
> not overly involved ones of those (plus a couple of subsequent findings)
> are taken care of. The rest is left to people more familiar with the
> inner workings of the operand type machinery.
> 
> 1: correct B16B16 indexed bf{mla,mls,mul}
> 2: check matching operands for predicated B16B16 insns
> 3: check tied operand specifier in aarch64-gen
> 4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate)
> 5: correct SVE2.1 ld2q (scalar plus scalar)
> 6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1
> 
> At least the last patch wants backporting to 2.42.
> 
> Jan

A general comment: we refer to the port as "AArch64", and typically use
"aarch64: ..." in commit message headers.

I've pushed a further gas/NEWS update on top of your already committed patch 6,
to match the change on the release branch.  Aside from the aforementioned
naming issues and my suggested error message improvement, the remainder of this
series looks good to me (although I can't formally approve anything).

(If/when this is merged, Srinath can rebase his other fixes on top of this
series.)
Jan Beulich March 18, 2024, 8:23 a.m. UTC | #2 
On 15.03.2024 17:20, Andrew Carlotti wrote:
> On Fri, Feb 23, 2024 at 12:26:37PM +0100, Jan Beulich wrote:
>> Some of the issues addressed here were pointed out before, but only
>> not overly involved ones of those (plus a couple of subsequent findings)
>> are taken care of. The rest is left to people more familiar with the
>> inner workings of the operand type machinery.
>>
>> 1: correct B16B16 indexed bf{mla,mls,mul}
>> 2: check matching operands for predicated B16B16 insns
>> 3: check tied operand specifier in aarch64-gen
>> 4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate)
>> 5: correct SVE2.1 ld2q (scalar plus scalar)
>> 6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1
>>
>> At least the last patch wants backporting to 2.42.
> 
> A general comment: we refer to the port as "AArch64", and typically use
> "aarch64: ..." in commit message headers.

I'm aware of aarch64 being the "arch identifier". I'm not alone though in
preferring Arm64 in textual uses - see Linux sources for a prominent
example.

> I've pushed a further gas/NEWS update on top of your already committed patch 6,
> to match the change on the release branch.  Aside from the aforementioned
> naming issues and my suggested error message improvement, the remainder of this
> series looks good to me (although I can't formally approve anything).
> 
> (If/when this is merged, Srinath can rebase his other fixes on top of this
> series.)

In the absence of arch maintainer comments I've committed the first two
patches. I'll reply to your comment on patch 3 separately. Having seen
Srinath's patches, I'm actually okay with dropping patches 4 and 5 from
here, in favor of his more complete fixes. Once patch 3 is in, he'd need
to rebase there, of course.

Jan
Richard Earnshaw (lists) May 9, 2024, 2:17 p.m. UTC | #3 
On 18/03/2024 08:23, Jan Beulich wrote:
> I'm aware of aarch64 being the "arch identifier". I'm not alone though in
> preferring Arm64 in textual uses - see Linux sources for a prominent
> example.

This isn't about personal preferences, though, it's about the port name; 
and that's aarch64.

There are good technical reasons for not using arm or anything with that 
in the name in that this is an entirely separate identifier.  There are 
many configure scripts out there that match arm* (or even, in some 
cases, arm6* which was a very early implementation of the Arm 32-bit 
architecture).  Having a distinct name really helps with avoiding 
problems stemming from that.

Mixing aarch64 and arm64 in commit tags also makes it more difficult to 
identify patches relating to the port (and also adds false matches for 
those searching for the 32-bit arm port).

Anyway, please can you use the official tag name in commits in future.

R.

PS: I'd point out that the x86 port is not called 'intel' either, 
perhaps for similar reasons.
Jan Beulich May 14, 2024, 6:57 a.m. UTC | #4 
On 09.05.2024 16:17, Richard Earnshaw (lists) wrote:
> 
> 
> On 18/03/2024 08:23, Jan Beulich wrote:
>> I'm aware of aarch64 being the "arch identifier". I'm not alone though in
>> preferring Arm64 in textual uses - see Linux sources for a prominent
>> example.
> 
> This isn't about personal preferences, though, it's about the port name; 
> and that's aarch64.
> 
> There are good technical reasons for not using arm or anything with that 
> in the name in that this is an entirely separate identifier.  There are 
> many configure scripts out there that match arm* (or even, in some 
> cases, arm6* which was a very early implementation of the Arm 32-bit 
> architecture).  Having a distinct name really helps with avoiding 
> problems stemming from that.
> 
> Mixing aarch64 and arm64 in commit tags also makes it more difficult to 
> identify patches relating to the port (and also adds false matches for 
> those searching for the 32-bit arm port).
> 
> Anyway, please can you use the official tag name in commits in future.

I'll try to keep that in mind, sure.

> PS: I'd point out that the x86 port is not called 'intel' either, 
> perhaps for similar reasons.

I find this comparison odd: There are various x86 parts from other vendors.
x86-64 wasn't even "invented" by Intel.

Jan