[PATCH RESEND v2] Aarch64: Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}
Shaokun Zhang
zhangshaokun@hisilicon.com
Thu Mar 10 11:33:41 GMT 2022
Hi Jan,
On 2022/3/10 18:38, Jan Beulich wrote:
> On 10.03.2022 10:38, Shaokun Zhang wrote:
>> Hi Jan,
>
> Despite this, ...
>
>> On 2022/3/2 15:36, Shaokun Zhang wrote:
>>> 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?
>
> ... I assume you understand that I'm not in the position to give you the
> wanted "okay"?
Apologies that I don't follow it completely, do you mean that does it need
someone to agree and take it? Or we need more comments?
Thanks,
Shaokun
>
> Jan
>
> .
>
More information about the Binutils
mailing list