https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125731
Bug ID: 125731
Summary: Improve RISC-V sequence for conditional xor with a
constant
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Given this function:
long fun_not1 (int a, long b)
{
if (!(a & 1))
b ^= 8;
return b;
}
Compiled with -march=rv64gcbv_zicond -O2 we currently get:
fun_not1:
andi a5,a0,1
mv a0,a1
bne a5,zero,.L3
xori a0,a1,8
.L3:
ret
But it's really just a conditional xor. We could instead generate:
andi a5,a0,1
li a4,8
czero.nez a5,a4,a5
xor a0,a1,a5
ret
It's the same number of instructions, but if the conditional branch is not
easily predictable, the branchless sequence will be much faster. There is an
alternate sequence that avoids the zicond extension, but it's likely marginally
slower and with zicond part of the rva23 profile, I doubt it's worth meaningful
time to try to generate the non-zicond sequence.
Like so many simplification issues, this can be handled in both gimple and RTL.
I want this BZ to focus on the RTL simplification. There's already a BZ that
effectively covers the gimple side (pr118360).
I think this is a failure in ifcvt.cc and fixing it would be a step towards
fixing pr124956 as well.
In particular ifcvt isn't handling the case where we have a CONST_INT operand.
It's requiring REG/SUBREG expressions only. See ifcvt.cc::get_base_reg and its
callers. We need to change that routine to allow CONST_INTs (which will
require a name change) and likely other minor changes since CONST_INT nodes do
not have a mode and I think we use the return value from this routine to
generate a new pseudo register (which needs a valid mode).
