On 6/6/19 12:45 PM, Peter Maydell wrote:
> + n = (a->imm4h << 28) & 0x80000000;
> + i = ((a->imm4h << 4) & 0x70) | a->imm4l;
> + if (i & 0x40) {
> + i |= 0x780;
> + } else {
> + i |= 0x800;
> + }
> + n |= i << 19;
Can we reuse vfp_expand_imm here? Given that you don't have pure code motion
from the old code (due to field extraction) it doesn't feel wrong to go ahead
and fix this wart now.
> +VMOV_imm_sp ---- 1110 1.11 imm4h:4 .... 1010 0000 imm4l:4 \
> + vd=%vd_sp
We should concatenate imm4h and imm4l here, so that trans_VMOV_imm_* only needs
to do "n = vfp_expand_imm(MO_32, a->imm);".
(We can't use !function to expand the whole float constant because the
decodetree fields are "int", and we'd need to store a "uint64_t" for dp. C.f.
the SVE trans_FDUP.)
r~
