On 2023-10-31 00:36 Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
>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<zengx...@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.
Exactly. 2 less insns for add case below：
long test_ADD_ceqz(long x, long y, long z, long c){
if (c)
x = y + z;
else
x = y;
return x;
}
test_ADD_ceqz(before this patch):
add a2,a1,a2
czero.eqz a0,a2,a3
czero.nez a3,a1,a3
or a0,a3,a0
ret
test_ADD_ceqz(after this patch):
czero.eqz a3,a2,a3
add a0,a1,a3
ret
>
>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.
As shown case above, 2 less insns with using condzero arith.
>
>
>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.
This series is a initial framework for simple condzero arith. Shift may come
later
as it involes sugreg stuff.
>
>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 searched and didn't find VRULL codes, could you please provide a link at
your convience? My colleague Zeng Xiao posted monthes ago
https://patchwork.sourceware.org/project/gcc/patch/20230719101156.21771-6-zengx...@eswincomputing.com/
But after fixing several bugs, we realized the previous implementation is quite
complex and
come up with this patch series.
>
>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.
Thanks for your patience.
BR,
Fei
>
>jeff
