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