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

[Shaokun Zhang]

Hi Jan,

On 2022/3/2 15:36, Shaokun Zhang wrote:
> 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.
> 

No any more comments from Arm guys.

Is it ok for trunk?

Thanks,
Shaokun

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