Re: [PATCH 30/37] target/i386: reimplement 0x0f 0x10-0x17, add AVX

[Paolo Bonzini]

On Tue, Sep 13, 2022 at 12:14 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
> > +static void gen_VMOVLPx(DisasContext *s, CPUX86State *env, X86DecodedInsn 
> > *decode)
> > +{
> > +    int vec_len = sse_vec_len(s, decode);
> > +
> > +    tcg_gen_ld_i64(s->tmp1_i64, cpu_env, decode->op[2].offset + 
> > offsetof(XMMReg, XMM_Q(0)));
> > +    tcg_gen_gvec_mov(MO_64, decode->op[0].offset, decode->op[1].offset, 
> > vec_len, vec_len);
> > +    tcg_gen_st_i64(s->tmp1_i64, cpu_env, decode->op[0].offset + 
> > offsetof(XMMReg, XMM_Q(0)));
> > +}
>
> You've just been moving i64 pieces in the other functions, why is this one 
> different using
> a gvec move in the middle?  I do wonder if a generic helper moving 
> offset->offset, with
> the comparison wouldn't be helpful within these functions, even when you know 
> off1 !=
> off2, due to Q(0) vs Q(1).

Because this one is the only one that has a VEX.256 version (the
operand is type "x"
rather than "dq" as in MOVHLPS, MOVLHPS, MOVHPx).

Paolo


Paolo