[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Henderson
Subject: Re: [PATCH v4 24/47] target/ppc: move vrl[bhwd]nm/vrl[bhwd]mi to decodetree
Date: Wed, 23 Feb 2022 12:19:34 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

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);


reply via email to

[Prev in Thread] Current Thread [Next in Thread]