On Tue, Sep 13, 2022 at 12:14 PM Richard Henderson
<richard.hender...@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
