On 11/27/23 19:32, Fei Gao wrote:
In x=c ? (y op CONST) : y cases, Zicond based czero ifcvt generates
more true dependency in code sequence than SFB based movcc. So exit
noce_try_cond_zero_arith in such cases to have a better code sequence
generated by noce_try_cmove_arith.

Take the following case for example.

CFLAGS: -mtune=sifive-7-series -march=rv64gc_zbb_zicond -mabi=lp64d -O2

unsigned int
test_RotateR_eqz_imm_int (unsigned int x, unsigned int y, unsigned int c)
{
   if (c)
     x = (y >> 11) | (y << (32 - 11));
   else
     x = y;
   return x;
}

before patch:
        li      a5,11
        czero.eqz       a2,a5,a2
        rorw    a0,a1,a2
        ret

after patch:
        roriw   a0,a1,11
        bne     a2,zero,1f      # movcc
        mv      a0,a1
1:
        ret

Co-authored-by: Xiao Zeng<zengx...@eswincomputing.com>

gcc/ChangeLog:

         * config/riscv/riscv.cc (riscv_have_sfb): hook implementation
         (TARGET_HAVE_SFB): define hook in riscv
         * doc/tm.texi: add TARGET_HAVE_SFB
         * doc/tm.texi.in: add TARGET_HAVE_SFB
         * ifcvt.cc (noce_try_cond_zero_arith): prefer SFB for x=c ? (y op 
CONST) : y
         * target.def:add TARGET_HAVE_SFB
This is not OK. It's basically a target #if. It's not significantly different than the original kit which had a hook to prefer czero over other forms.


Selection between the two forms should be drive by the target cost modeling and expansion code. Using a hook like this isn't acceptable.


Jeff

Reply via email to