On 7/28/23 00:34, Xiao Zeng wrote:
What I like about yours is it keeps all the logic in riscv.cc rather
than scattering it across riscv.cc and riscv.md.
Yes, when I use enough test cases, I cannot find a concise way to optimize
all test cases. When I enumerated all possible cases in the mov<mode>cc
function of the RISC-V backend, I found a method that satisfied me, which
is the method in patch [3/5].
I continue to work with the riscv_expand_conditional_move improvements.
Given the deeper problems we have with costing, I'm considering starting
to push some of the riscv_expand_conditional_move work you've done
without the testcases since those testcases depend on fixing the costing
problems.
The expansion changes still have value without the costing changes.
When we expand a COND_EXPR from gimple, we will attempt to use the
conditional move pattern first, without regard for costing.
If it's just for the Zicond instruction set, is it necessary to make judgments
outside of eq/ne? After all, it does not support comparison actions other
than eq/ne. Of course, it is also possible to use a special technique to use
Zicond in non eq/ne comparisons.
It's not necessary, but it's certainly helpful to utilize sCC insns in
conjuction with zicond to if-convert other conditional branches. It's
conceptually pretty simple.
If the incoming code is not EQ/NE or we're not comparing a register
against 0, then we can emit an scc insn to get the comparison result
into a temporary, then use the standard zicond expansions.
Jeff
