[PATCH RESEND v2] Aarch64: Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}

Shaokun Zhang zhangshaokun@hisilicon.com
Wed Mar 2 07:36:07 GMT 2022


Hi Jan,

On 2022/2/21 21:13, Jan Beulich wrote:
> On 16.02.2022 01:53, Shaokun Zhang wrote:
>> --- a/gas/testsuite/gas/aarch64/sve-movprfx_23.d
>> +++ b/gas/testsuite/gas/aarch64/sve-movprfx_23.d
>> @@ -9,29 +9,29 @@ Disassembly of section .*:
>>  
>>  0+ <.*>:
>>  [^:]+:	04512461 	movprfx	z1.h, p1/m, z3.h
>> -[^:]+:	256c8021 	incp	z1.h, p1  // note: merging predicate expected due to preceding `movprfx' at operand 2
>> +[^:]+:	256c8021 	incp	z1.h, p1.h  // note: merging predicate expected due to preceding `movprfx' at operand 2
> 
> I have a more general question here: Couldn't the spec make optional the
> use of all the same size specifiers when there are multiple, same element
> size operands? One such suffix of course needs to be there to disambiguate

We are not from ARM SPEC group and don't know the exact considerations for
the forbidden omitting suffix. We guess people will have different answers from
different points of view.

>From our point of view,  a suffix makes the assembly more consistent with the
scalar versions of `incp`, e.g. `incp x1, p2.b`. And the predicate register acts more
like a vector register within this instruction, with suffix, the addend for each element
is clear once reading the assembly string.

Not sure that anyone from ARM in the mail-list can give more hints or thoughts.

Cheers,


> different element size forms of the same insn, but the redundancy merely
> adds clutter imo.
> 
> Jan
> 
> .
> 


More information about the Binutils mailing list