Re: [PATCH v4 24/47] target/ppc: move vrl[bhwd]nm/vrl[bhwd]mi to decodetree

[Richard Henderson]

On 2/23/22 11:43, Matheus K. Ferst wrote:
> > Note that rotlv does the masking itself:
> >
> > /*
> >   * Expand D = A << (B % element bits)
> >   *
> >   * Unlike scalar shifts, where it is easy for the target front end
> >   * to include the modulo as part of the expansion.  If the target
> >   * naturally includes the modulo as part of the operation, great!
> >   * If the target has some other behaviour from out-of-range shifts,
> >   * then it could not use this function anyway, and would need to
> >   * do it's own expansion with custom functions.
> >   */
>
> Using tcg_gen_rotlv_vec(vece, vrt, vra, vrb) works on PPC but fails on x86. It looks like 
> a problem on the i386 backend. It's using VPS[RL]LV[DQ], but instead of this modulo 
> behavior, these instructions write zero to the element[1]. I'm not sure how to fix that. 

You don't want to use tcg_gen_rotlv_vec directly, but tcg_gen_rotlv_vec.

The generic modulo is being applied here:

static void tcg_gen_rotlv_mod_vec(unsigned vece, TCGv_vec d,
                                  TCGv_vec a, TCGv_vec b)
{
    TCGv_vec t = tcg_temp_new_vec_matching(d);
    TCGv_vec m = tcg_constant_vec_matching(d, vece, (8 << vece) - 1);

    tcg_gen_and_vec(vece, t, b, m);
    tcg_gen_rotlv_vec(vece, d, a, t);
    tcg_temp_free_vec(t);
}


r~