https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117011
Bug ID: 117011
Summary: RISC-V: Logic overlap in IF_THEN_ELSE case for
instruction cost calculation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jovan.vu...@rt-rk.com
Target Milestone: ---
Target: riscv
In the file riscv.cc, in the function riscv_rtx_costs, we have the
following code for the IF_THEN_ELSE case:
if ((TARGET_SFB_ALU || TARGET_XTHEADCONDMOV)
&& reg_or_0_operand(XEXP(x, 1), mode)
&& sfb_alu_operand(XEXP(x, 2), mode)
&& comparison_operator(XEXP(x, 0), VOIDmode))
{
/* For predicated conditional-move operations, we assume the cost
of a single instruction, even though there are actually two. */
*total = COSTS_N_INSNS(1);
return true;
}
else if (TARGET_ZICOND_LIKE
&& outer_code == SET
&& ...)
{
*total = COSTS_N_INSNS(1);
return true;
}
However, what will happen if both TARGET_SFB_ALU and
TARGET_ZICOND_LIKE are set to 1 at the same time
(-mtune=sifive-7-series -march=rv64gc_zicond)? In this case, we won't be
able to distinguish between the movcc and czero instructions, and for
czero, we will enter the "if" branch instead of (as we expect) the
"else if" branch.
Since both branches currently set *total to 1 instruction, there is
essentially no difference. However, if someone changes the way the
calculation is performed in the future, it could lead to issues.
