[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 26/36] target/arm: Convert Neon VQSHL, VRSHL, VQRSHL 3-reg-sa
From: |
Peter Maydell |
Subject: |
Re: [PATCH 26/36] target/arm: Convert Neon VQSHL, VRSHL, VQRSHL 3-reg-same insns to decodetree |
Date: |
Fri, 1 May 2020 19:10:12 +0100 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 26/36] target/arm: Convert Neon VQSHL, VRSHL, VQRSHL 3-reg-same insns to decodetree,
Peter Maydell <=