On 6/17/25 1:56 AM, Kito Cheng wrote:
Motivation of this patch is we want to use ld/sd if possible when zilsd
is enabled, however the subreg pass may split that into two lw/sw
instructions because the cost, and it only check cost for 64 bits reg move,
that's why we need adjust cost for 64 bit reg move as well.

However even we adjust the cost model, 64 bit shift still use 32 bit
load because it already got split at expand time, this may need to fix
on the expander side, and this apparently need few more time to
investigate, so I just added a testcase with XFAIL to show the current behavior,
and we can fix that...when we have time.

For long term, we may adding a new field to riscv_tune_param to control
the cost model for that.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_cost_model): Add cost model for zilsd.

gcc/testsuite/Changelog:

        * gcc.target/riscv/zilsd-code-gen-split-subreg-1.c: New test.
        * gcc.target/riscv/zilsd-code-gen-split-subreg-2.c: New test.
No strong opinions here since the changes are conditional on zilsd. So if you're comfortable and CI is happy, then I think we can move forward. If we need to adjust in the future we certainly can. Just a couple nits.




+/* Check if the mode is twice the size of the XLEN mode. */
+
+static bool
+riscv_2x_xlen_mode_p (machine_mode mode)
+{
+  poly_int64 mode_size = GET_MODE_SIZE (mode);
+  return  mode_size.is_constant () &&
+         (mode_size.to_constant () == UNITS_PER_WORD * 2);
+}
Formatting.  Probably best to format like:

  return (mode_size.is_constant ()
          && mode_size.to_constant () == UNITS_PER_WORD * 2);



+
+         /* Register move for XLEN * 2.  */
+         if (TARGET_ZILSD
+             && register_operand (SET_SRC (x), GET_MODE (SET_SRC (x)))
+             && riscv_2x_xlen_mode_p (mode))
+           {
+             /* We still need two instrcution for move with ZILSD,
+                but let minus one cost to let subreg split don't.
+                TODO: Add riscv_tune_param for this.  */
Misspelled "instruction".


Jeff

Reply via email to