[V2] RISC-V: Fix RVV can change mode class bug

Message ID 20230919025922.1898652-1-juzhe.zhong@rivai.ai
State Committed
Delegated to: Robin Dapp
Series [V2] RISC-V: Fix RVV can change mode class bug |


Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 success Testing passed

Commit Message

juzhe.zhong@rivai.ai Sept. 19, 2023, 2:59 a.m. UTC
  After support the VLS mode conversion, current case triggers a latent bug that we are
lucky we didn't encounter.

This is a real bug in 'cprop_hardreg':

during RTL pass: cprop_hardreg
auto.c: In function 'main':
auto.c:79:1: internal compiler error: in partial_subreg_p, at rtl.h:3186
   79 | }
      | ^
0x10979a7 partial_subreg_p(machine_mode, machine_mode)
0x1723eda mode_change_ok
0x1724007 maybe_mode_change
0x172445d find_oldest_value_reg
0x172534d copyprop_hardreg_forward_1
0x1727017 cprop_hardreg_bb
0x17272f7 execute

When trying to do reg copy propagation between RVVMF8BI (precision = 16,16)
and V32BI (precision = 32,0).

The assertion failed in partial_subreg_p:
gcc_checking_assert (ordered_p (outer_prec, inner_prec));

In regcprop.cc:

  if (partial_subreg_p (orig_mode, new_mode))
    return false;

If orig_mode (RVVMF8BI) smaller than new_mode (V32BI), we don't do the hard reg propogation.
However, the 'partial_subreg_p' cause ICE since gcc_checking_assert (ordered_p (outer_prec, inner_prec)).

After analysis in aarch64.cc, they do careful block in 'TARGET_CAN_CHANGE_MODE_CLASS'.
So it's reasonable block regcprop when old mode size maybe_lt than new mode size since we won't do the
copy propgation.


	* config/riscv/riscv.cc (riscv_can_change_mode_class): Block unordered VLA and VLS modes.

 gcc/config/riscv/riscv.cc | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)


Robin Dapp Sept. 19, 2023, 12:04 p.m. UTC | #1
Hi Juzhe,

I'd agree that punting is reasonable for now, therefore LGTM.

Lehua Ding Sept. 19, 2023, 12:07 p.m. UTC | #2
Committed, thanks Robin.

On 2023/9/19 20:04, Robin Dapp wrote:
> Hi Juzhe,
> I'd agree that punting is reasonable for now, therefore LGTM.
> Regards
>   Robin


diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 8c766e2e2be..f1b721d54d1 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8536,12 +8536,26 @@  riscv_slow_unaligned_access (machine_mode, unsigned int)
 static bool
-riscv_can_change_mode_class (machine_mode, machine_mode, reg_class_t rclass)
+riscv_can_change_mode_class (machine_mode from, machine_mode to,
+			     reg_class_t rclass)
+  /* We have RVV VLS modes and VLA modes sharing same REG_CLASS.
+     In 'cprop_hardreg' stage, we will try to do hard reg copy propagation
+     between wider mode (FROM) and narrow mode (TO).
+     E.g. We should not allow copy propagation
+	- RVVMF8BI (precision = [16, 16]) -> V32BI (precision = [32, 0])
+     since we can't order their size which will cause ICE in regcprop.
+     TODO: Even though they are have different size, they always change
+     the whole register.  We may enhance such case in regcprop to optimize
+     it in the future.  */
+  if (reg_classes_intersect_p (V_REGS, rclass)
+      && !ordered_p (GET_MODE_PRECISION (from), GET_MODE_PRECISION (to)))
+    return false;
   return !reg_classes_intersect_p (FP_REGS, rclass);