Re: [PATCH 2/4] [ifcvt] if convert x=c ? y+z : y by RISC-V Zicond like insns

[Jeff Law <jeffreyalaw@gmail.com>]

On 10/30/23 01:25, Fei Gao wrote:
> Conditional add, if zero
> rd = (rc == 0) ? (rs1 + rs2) : rs1
> -->
> czero.nez rd, rs2, rc
> add rd, rs1, rd
> 
> Conditional add, if non-zero
> rd = (rc != 0) ? (rs1 + rs2) : rs1
> -->
> czero.eqz rd, rs2, rc
> add rd, rs1, rd
> 
> Co-authored-by: Xiao Zeng<zengxiao@eswincomputing.com>
> 
> gcc/ChangeLog:
> 
>          * ifcvt.cc (noce_emit_czero): helper for noce_try_cond_zero_arith
>          (noce_try_cond_zero_arith): handler for condtional zero op
>          (noce_process_if_block): add noce_try_cond_zero_arith with hook control
> 
> gcc/testsuite/ChangeLog:
> 
>          * gcc.target/riscv/zicond_ifcvt_opt.c: New test.
So the idea here is to improve upon the current code we generate for 
conditional arithmetic.  Right now we support conditional arithmetic 
using zicond, but the sequence is poor.

Basically the if-converter knows how to generate a conditional add, but 
it does so in a way that isn't as efficient as it could be.

In effect ifcvt wants to generate

t = a + b
res = cond ? t : b


We want to change it to

t = cond ? b : 0;
res = a + t;

The latter sequence expands to more efficient code trivially for risc-v.

I wandered a bit through the combine dumps to see if it would be easy to 
capture this class of cases.  We never get anything useful, and while I 
can imagine "bridge" patterns that would potentially expose enough RTL 
to allow us to rewrite without changing ifcvt, it'd just be a hack IMHO.

So going back to ifcvt...

In the first sequence the addition must wait for both "a" and "b" to be 
available and the conditional move can fire on the next cycle.

In the second sequence the conditional move can fire when just "b" is 
available.  So that gives "a" another cycle to become ready (say if it's 
coming from memory or a multi-cycle operation like multiply).

On the other hand the second sequence does keep "a" live longer.

In the end I strongly suspect neither sequence is significantly better 
than the other.  Meaning I don't think we need to conditionalize using 
condzero arith at all.


I'll note that subsequent patches add MINUS, IOR, XOR and AND.  It's 
also possible (and important) to handle shifts.  There's a conditional 
shift-by-6 in leela's hot path.

Overall this looks a lot like the VRULL code, but just less complete. 
My inclination is to do a cleanup pass on the VRULL code verify it 
handles all the cases in your tests and commit the VRULL implementation 
with your tests.

I'll do some further poking at this today.  Thanks for re-submitting 
these bits.  Getting this target independent work cleaned up has been on 
my TODO for a while now.

jeff