On 9/16/24 2:11 AM, Xianmiao Qu wrote:
Currently, the cost of the LO_SUM expression is based on
the cost of calculating the first subexpression.
And that's probably the real bug here. THe first subexpression is
typically going to be a REG and is not interesting from a costing
standpoint. What is far more interesting is the second subexpression
which is typically going to be a symbolic constant which can have
varying costs.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1b4a5c39c667..cb9692dad715 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3994,7 +3994,10 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBUTE_UN
return false;
case LO_SUM:
- *total = set_src_cost (XEXP (x, 0), mode, speed);
+ if (outer_code == SET && REG_P (XEXP (x, 0)))
+ *total = COSTS_N_INSNS (1);
+ else
+ *total = set_src_cost (XEXP (x, 0), mode, speed);
return true;
So rather than what you've done, I'd revert to the original form and
change XEXP (x, 0) to XEXP (x, 1). Or better yet add the two costs
together. Something like this:
*total = (set_src_cost (XEXP (x, 0), mode, speed)
+ set_src_cost (XEXP (x, 1), mode, speed));
One of the "quirks" of the costing interfaces is they can be passed RTL
which won't match any backend pattern and sometimes computing costs of
such RTL is useful. By adding the cost of the two subexpresions we
should handle that case more gracefully.
jeff
