From patchwork Wed May 24 01:57:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "juzhe.zhong@rivai.ai" X-Patchwork-Id: 1785500 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4QQvTd0SnXz20PY for ; Wed, 24 May 2023 11:57:56 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E303F3858434 for ; Wed, 24 May 2023 01:57:53 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) by sourceware.org (Postfix) with ESMTPS id 2F9A43858D37 for ; Wed, 24 May 2023 01:57:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F9A43858D37 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: bizesmtp83t1684893450tmkl08r8 Received: from rios-cad5.localdomain ( [58.60.1.11]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 24 May 2023 09:57:29 +0800 (CST) X-QQ-SSF: 01400000000000F0R000000A0000000 X-QQ-FEAT: 3M0okmaRx3gSbqUlMdelevC/IRHHr4bIgmQzTT3+OYiUyP91g0LlsQBkVLZy8 3gTj2AqQvPfqbqbJ3gOVaK3EpDtHUt3tj5vCw9UMsDVMej1RmTIqOB7OlUHmquGksLTulFo Q+Z2au/ykc2hYGIvDamGe0jw2dQwaNdB0h9RQatfYyKlO+VD32LPmVMfvxFap5LULNqTDno 0IvGQ7WpFYtCqgnbA4MFCrK1sGIzHVyGKp8EsOihftk5iu0Qfx7D91asKHLYJIA0TEPD8ly vonCrBM5iVUfEou/z2cnM08J+GVtWb908p7HGnq33Ugto4QS94LGrTiT/ALS8KBNJkwKLwy 48F/rbxyhEa6EGVxbA0eWVWw1gbTt+vpDnZZ2u46b4af+w2wqfKTlmk1R/2HhnYZ7XKOQD0 X-QQ-GoodBg: 2 X-BIZMAIL-ID: 18079392677378202464 From: juzhe.zhong@rivai.ai To: gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, kito.cheng@sifive.com, palmer@dabbelt.com, palmer@rivosinc.com, jeffreyalaw@gmail.com, rdapp.gcc@gmail.com, Juzhe-Zhong Subject: [PATCH] RISC-V: Fix incorrect code of touching inaccessible memory address Date: Wed, 24 May 2023 09:57:27 +0800 Message-Id: <20230524015727.1157568-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.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" From: Juzhe-Zhong For VLMAX situation, rtx len = ops[m_op_num] is incorrect since the last element the ops array should be ops[m_op_num - 1]; I notice this issue when I am debugging code. This is a code bug even though the following codes will hide this issue. We still should need this minor fix. Built && Regression PASSed. Ok for trunk? gcc/ChangeLog: * config/riscv/riscv-v.cc: Fix bug of touching inaccessible memory. --- gcc/config/riscv/riscv-v.cc | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc index fa61a850a22..a0992773644 100644 --- a/gcc/config/riscv/riscv-v.cc +++ b/gcc/config/riscv/riscv-v.cc @@ -169,7 +169,11 @@ public: if (m_needs_avl_p) { - rtx len = ops[m_op_num]; + /* The variable "m_op_num" means the real operation operands except VL + operand. For VLMAX patterns (no VL operand), the last operand is + ops[m_op_num -1]. Wheras for non-VLMAX patterns, the last operand is + VL operand which is ops[m_op_num]. */ + rtx len = NULL_RTX; if (m_vlmax_p) { if (const_vlmax_p (m_dest_mode)) @@ -185,6 +189,20 @@ public: len = gen_reg_rtx (Pmode); emit_vlmax_vsetvl (m_dest_mode, len); } + else + { + /* According to LRA mov pattern in vector.md. The VL operand is + always the last operand. */ + gcc_assert (ops[m_op_num]); + len = ops[m_op_num]; + } + } + else + { + /* For non-VLMAX patterns. The VL operand is always the last + * operand. */ + gcc_assert (ops[m_op_num]); + len = ops[m_op_num]; } add_input_operand (len, Pmode); }