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

[Richard Henderson]

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~