On 5/16/21 11:09 AM, Peter Maydell wrote:
On Sat, 15 May 2021 at 18:13, Richard Henderson
<richard.hender...@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~
