Re: [PATCH 26/36] target/arm: Convert Neon VQSHL, VRSHL, VQRSHL 3-reg-same insns to decodetree

[Peter Maydell]

On Fri, 1 May 2020 at 02:55, Richard Henderson
<address@hidden> wrote:
> I'm not 100% sure how best to handle the swapped operands issue.  I don't 
> think
> we want to do it here in gen_gvec_srshl, because we don't have the same 
> reverse
> operand problem in the aarch64 encoding, and I'm looking forward to re-using
> this generator function in aa64 and sve2.
>
> Maybe it would be better to have
>
> @3same     .... ... . . . size:2 .... .... .... . q:1 . . .... \
>            &3same vm=%vm_dp vn=%vn_dp vd=%vd_dp
> @3same_rev .... ... . . . size:2 .... .... .... . q:1 . . .... \
>            &3same vn=%vm_dp vm=%vn_dp vd=%vd_dp
>
> and swap the operands to "normal" during decode.

Yeah, I guess so. It's a little confusing because the operands
are going to appear with the "wrong" names in the trans_ functions,
but we can hopefully deflect some of that with a suitable comment
by the @3same_rev format definition.

I think that all the affected insns have asm formats like
 VSHL <Dd>, <Dm>, <Dn>
in contrast to eg
 VSUB <Dd>, <Dn>, <Dm>

so it's effectively just that the field names in the official
insn definition are backwards from what you'd expect.

thanks
-- PMM