Re: [PATCH v6 77/82] target/arm: Fix decode for VDOT (indexed)

[Richard Henderson <richard.henderson@linaro.org>]

On 5/16/21 11:09 AM, Peter Maydell wrote:
> On Sat, 15 May 2021 at 18:13, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> On 5/13/21 2:25 PM, Peter Maydell wrote:
>>>> -VDOT_scalar    1111 1110 0 . 10 .... .... 1101 . q:1 index:1 u:1 rm:4 \
>>>> -               vm=%vm_dp vn=%vn_dp vd=%vd_dp
>>>> +VDOT_scalar    1111 1110 0 . 10 .... .... 1101 . q:1 index:1 u:1 vm:4 \
>>>> +               vn=%vn_dp vd=%vd_dp
>>>
>>> Is it possible to make this kind of bug a decodetree error?
>>> It seems unlikely that there's a use for having a bit which is
>>> decoded both by a %foo field specification and also in some
>>> other way...
>>
>> That's not what's happening here.  This has separate fields "rm" and "vm"
>> decoded in different ways.
> 
> But they overlap: rm:4 in the pattern itself is using bits [3:0],
> and "vm=%vm_dp" is also using [3:0] because the %vm_dp field
> specifier is defined as "5:1 0:4". I'm suggesting that if the
> pattern uses a field specifier we should check that none of the
> bits in that field specifier are used in the pattern for some
> other purpose (here 'u' and 'rm').

We do this, more or less, for sve:

# Three register operand, with governing predicate, vector element size
@rda_pg_rn_rm   ........ esz:2 . rm:5  ... pg:3 rn:5 rd:5 \
                 &rprrr_esz ra=%reg_movprfx

where ra and rd overlap.  Though ra and rd overlap exactly, so perhaps that's 
not quite the same as vm above, overlapping both rm and index.


r~