From patchwork Tue Sep 19 02:25:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?6ZKf5bGF5ZOy?= X-Patchwork-Id: 76338 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 66410385770A for ; Tue, 19 Sep 2023 02:26:27 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtpbg151.qq.com (smtpbg151.qq.com [18.169.211.239]) by sourceware.org (Postfix) with ESMTPS id EDBA23858D32 for ; Tue, 19 Sep 2023 02:26:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDBA23858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai X-QQ-mid: bizesmtp78t1695090361txdm50yk Received: from rios-cad121.hadoop.rioslab.org ( [58.60.1.9]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 19 Sep 2023 10:26:00 +0800 (CST) X-QQ-SSF: 01400000000000G0V000000A0000000 X-QQ-FEAT: zT6n3Y95oi2EvvRPBrjR7xlCfs5sZxapQmTa/vo1TO1uX2LWxZ6TExuLzyaU0 s1CXWv57fznpFC6+gTGcihDARLBDOfVkp/Mxo+YFJjFpvjX/kuZEKll8k6CAKLI0G6/5IkV hyLKbtx8hv5FE4GYvqz6/rlzTPyRYCSO3DAwWHnjaJOfEPMsa0i0qH/QklztC63K0QkoHSq KagzgTehH7Y/dkEsxPKsifsTAKBBXHcQVm/K+TmBPRUP9SBUmFAFKK2/HRyc3UtlP0ixAZg PdSg0HLiveHQZ34nUDXMbjP3EJ0c+vUA5xXbCFBlZDfMdf4rG/wGMWcVZVk+KiMGElT93Rl 3PZbVF0hCBSR8CDHSZ6NkIrR7Ly11tzqlBPxtSZGfQ5K7R1FgOLJ14YlV5BAg== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 213944673728193273 From: Juzhe-Zhong To: gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, kito.cheng@sifive.com, jeffreyalaw@gmail.com, rdapp.gcc@gmail.com, Juzhe-Zhong Subject: [PATCH] RISC-V: Fix RVV can change mode class bug Date: Tue, 19 Sep 2023 10:25:59 +0800 Message-Id: <20230919022559.1879725-1-juzhe.zhong@rivai.ai> X-Mailer: git-send-email 2.36.3 MIME-Version: 1.0 X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz7a-one-0 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" 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': orig:RVVMF8BI,16,16 new:V32BI,32,0 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) ../../../../gcc/gcc/rtl.h:3186 0x1723eda mode_change_ok ../../../../gcc/gcc/regcprop.cc:402 0x1724007 maybe_mode_change ../../../../gcc/gcc/regcprop.cc:436 0x172445d find_oldest_value_reg ../../../../gcc/gcc/regcprop.cc:489 0x172534d copyprop_hardreg_forward_1 ../../../../gcc/gcc/regcprop.cc:808 0x1727017 cprop_hardreg_bb ../../../../gcc/gcc/regcprop.cc:1358 0x17272f7 execute ../../../../gcc/gcc/regcprop.cc:1425 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. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_can_change_mode_class): Fix RVV mode change bug. --- gcc/config/riscv/riscv.cc | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index 8c766e2e2be..28b45a87351 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -8536,8 +8536,22 @@ riscv_slow_unaligned_access (machine_mode, unsigned int) /* Implement TARGET_CAN_CHANGE_MODE_CLASS. */ 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 such propagation cause ICE and execution FAIL. + + However, we could allow copy propagation + - RVVMF4 (precision = [32, 32]) -> V32BI (precision = [32, 0]) + since RVVMF4 always >= RV32BI. */ + if (reg_classes_intersect_p (V_REGS, rclass) + && maybe_lt (GET_MODE_PRECISION (from), GET_MODE_PRECISION (to))) + return false; return !reg_classes_intersect_p (FP_REGS, rclass); }