[PATCH] Fix the disassembly of the AArch64 SVE DECP/INCP/SQDECP/SQINCP instruction.

[Jan Beulich]

On 09.02.2022 01:56, Shaokun Zhang wrote:
> On 2022/2/7 17:44, Jan Beulich wrote:
>> On 07.02.2022 10:34, Shaokun Zhang via Binutils wrote:
>>> From: Jingtao Cai <caijingtao@huawei.com>
>>>
>>> This patch fix qualifier for the AArch64 SVE DECP/INCP/SQDECP/SQINCP instruction, which take the predicate size specifier:
>>> 	DECP <Zdn>.<T>, <Pm>.<T>
>>> 	INCP <Zdn>.<T>, <Pm>.<T>
>>> 	SQINCP <Zdn>.<T>, <Pm>.<T>
>>> 	SQDECP <Zdn>.<T>, <Pm>.<T>
>>>
>>> Omitted predicate size specifier will be prohibited in a future release of the architecture, please refer to Arm A64 Instruction set documentation for Armv8-A
>>> architecture profile, see document[0].
>>>
>>> [0]: https://developer.arm.com/documentation/ddi0596/2021-12/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-
>>>
>>> E.g. :
>>>
>>> DECP Z1.H, P0.H
>>>
>>> This patch adds support for this kind of operand.
>>>
>>> DECP Z1.H, P0
>>>
>>> This instruction leads to messages:
>>> Assembler messages:
>>> Error: operand mismatch -- `decp Z1.h,P0'
>>
>> IOW unlike the title suggests you change not only the disassembly
> 
> Correct, current title is not quite accurate and how about `aarch64:
> allow explicit size specifier for predicate operand of decp/incp`?

If, as you say below, the diagnostic becomes a warning, then "allow"
reads fine to me. If it was to remain an error, "require" would seem
more appropriate.

Jan

>> logic. Wouldn't it be better to make this a warning initially, and
>> convert to an error only a few releases later? That way people
>> don't need to immediately fix their code.
>>
> 
> Agree, we can make both `decp z1.h, p0` and `decp z1.h, p0.h` get
> assembled successfully and emit an warning for `decp z1.h, p0`,
> then everyone will be happy for now.
> 
>>> 	did you mean this?
>>> 		decp z1.h, p0.h
>>> 	other valid variant(s):
>>> 		decp z1.s, p0
>>> 		decp z1.d, p0
>>
>> Isn't this misleading? Should these "other valid variant(s)" also
>> be output with suffixes?
>>
> 
> Oops, apologies for the stupid typo, it does output with suffixes actually.
> 
> Thanks,