From patchwork Sun Mar 10 03:13:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Li, Pan2" X-Patchwork-Id: 1910169 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=QfqRaaY3; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TslPg2z6Yz1yWy for ; Sun, 10 Mar 2024 14:14:29 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2E55B3860772 for ; Sun, 10 Mar 2024 03:14:27 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by sourceware.org (Postfix) with ESMTPS id BCBCD385DC26 for ; Sun, 10 Mar 2024 03:14:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCBCD385DC26 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BCBCD385DC26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710040445; cv=none; b=W6NcatTn8iZzAfJpx2CJiWu3GiDB4HihKtjtneZaT21oxsijqQ+BMo7S0SWOttsmVjKxVuZj2WcSWe3zwnmrejBszLj5AhoOfBCXpdMNXSWawB1kTdLcc/6mqitLCyFZ7SRDfG7fqZhaX8FCVZBvX1zJGTnPS3/qEQVU7c1Zujs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710040445; c=relaxed/simple; bh=anWZVoD6ke1KI6EIKWDlBUFxkrchY4foeJK6DMQL9oY=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=Fhu62NiEkLCpcPilaijrJGkwEcNGmr2GRRg8eYd6K4CV0fXgAMFZciBK1dKl/maGJw62+F27rbdSZqYRJI9NwoJbJIqbTxbFcXcIYTb+UuanYqE0Zxl6zi53fcMTla/2H62B7aEZgsNewJfqCMXQiPjtlLkQCuAO4NyF6Ryli7o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710040442; x=1741576442; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=anWZVoD6ke1KI6EIKWDlBUFxkrchY4foeJK6DMQL9oY=; b=QfqRaaY3G+eTIvmgbJ4nAEptufrGYhT263DQJRoZr3CjmFURNtcO+XW7 apsYneB8r4oEYyRh48BkwoG5Q7rt2rMs+QeMp5xwSbiURDoX1AmQraHky M/Iv+WQRiPnpNDgvF0oe5zQ4A8UY9g8USkhE7SEUD+BmvsDH462B9IUpR mPEC3Ft8fv0TVpIkrddDIC5zY0DHu7I0V8Zmt/FlydaY6pOroAOseqbZm kPWGh5eMXUNkfCbIGdT3KzluwXRRQSKzDxykhSdJUUnDZeK9fkyiWmGww ZhCMoXz9Jttp/2j8YwmrkjB1rnv7wfjDb9BjdNHmM3OjHLQoTbhOitPgk A==; X-IronPort-AV: E=McAfee;i="6600,9927,11008"; a="22252704" X-IronPort-AV: E=Sophos;i="6.07,113,1708416000"; d="scan'208";a="22252704" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2024 19:14:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,113,1708416000"; d="scan'208";a="10838591" Received: from shvmail02.sh.intel.com ([10.239.244.9]) by orviesa010.jf.intel.com with ESMTP; 09 Mar 2024 19:13:58 -0800 Received: from pli-ubuntu.sh.intel.com (pli-ubuntu.sh.intel.com [10.239.159.47]) by shvmail02.sh.intel.com (Postfix) with ESMTP id 467CC10056B1; Sun, 10 Mar 2024 11:13:57 +0800 (CST) From: pan2.li@intel.com To: gcc-patches@gcc.gnu.org Cc: juzhe.zhong@rivai.ai, kito.cheng@gmail.com, yanzhang.wang@intel.com, rdapp.gcc@gmail.com, richard.guenther@gmail.com, jeffreyalaw@gmail.com, Pan Li Subject: [PATCH v2] VECT: Fix ICE for vectorizable LD/ST when both len and store are enabled Date: Sun, 10 Mar 2024 11:13:56 +0800 Message-Id: <20240310031356.1506268-1-pan2.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308000401.2766685-1-pan2.li@intel.com> References: <20240308000401.2766685-1-pan2.li@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, 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+incoming=patchwork.ozlabs.org@gcc.gnu.org From: Pan Li This patch would like to fix one ICE in vectorizable_store when both the loop_masks and loop_lens are enabled. The ICE looks like below when build with "-march=rv64gcv -O3". during GIMPLE pass: vect test.c: In function ‘d’: test.c:6:6: internal compiler error: in vectorizable_store, at tree-vect-stmts.cc:8691 6 | void d() { | ^ 0x37a6f2f vectorizable_store .../__RISC-V_BUILD__/../gcc/tree-vect-stmts.cc:8691 0x37b861c vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) .../__RISC-V_BUILD__/../gcc/tree-vect-stmts.cc:13242 0x1db5dca vect_analyze_loop_operations .../__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:2208 0x1db885b vect_analyze_loop_2 .../__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3041 0x1dba029 vect_analyze_loop_1 .../__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3481 0x1dbabad vect_analyze_loop(loop*, vec_info_shared*) .../__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3639 0x1e389d1 try_vectorize_loop_1 .../__RISC-V_BUILD__/../gcc/tree-vectorizer.cc:1066 0x1e38f3d try_vectorize_loop .../__RISC-V_BUILD__/../gcc/tree-vectorizer.cc:1182 0x1e39230 execute .../__RISC-V_BUILD__/../gcc/tree-vectorizer.cc:1298 There are two ways to reach vectorizer LD/ST, one is the analysis and the other is transform. We cannot have both the lens and the masks enabled during transform but it is valid during analysis. Given the transform doesn't required cost_vec, we can only enable the assert based on cost_vec is NULL or not. Below testsuites are passed for this patch: * The x86 bootstrap tests. * The x86 fully regression tests. * The aarch64 fully regression tests. * The riscv fully regressison tests. gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_store): Enable the assert during transform process. (vectorizable_load): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr114195-1.c: New test. Signed-off-by: Pan Li --- .../gcc.target/riscv/rvv/base/pr114195-1.c | 15 +++++++++++++++ gcc/tree-vect-stmts.cc | 18 ++++++++++++++---- 2 files changed, 29 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr114195-1.c diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr114195-1.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr114195-1.c new file mode 100644 index 00000000000..a67b847112b --- /dev/null +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr114195-1.c @@ -0,0 +1,15 @@ +/* Test that we do not have ice when compile */ +/* { dg-do compile } */ +/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -ftree-vectorize" } */ + +long a, b; +extern short c[]; + +void d() { + for (int e = 0; e < 35; e = 2) { + a = ({ a < 0 ? a : 0; }); + b = ({ b < 0 ? b : 0; }); + + c[e] = 0; + } +} diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc index 14a3ffb5f02..e8617439a48 100644 --- a/gcc/tree-vect-stmts.cc +++ b/gcc/tree-vect-stmts.cc @@ -8697,8 +8697,13 @@ vectorizable_store (vec_info *vinfo, ? &LOOP_VINFO_LENS (loop_vinfo) : NULL); - /* Shouldn't go with length-based approach if fully masked. */ - gcc_assert (!loop_lens || !loop_masks); + /* The vect_transform_stmt and vect_analyze_stmt will go here but there + are some difference here. We cannot enable both the lens and masks + during transform but it is allowed during analysis. + Shouldn't go with length-based approach if fully masked. */ + if (cost_vec == NULL) + /* The cost_vec is NULL during transfrom. */ + gcc_assert ((!loop_lens || !loop_masks)); /* Targets with store-lane instructions must not require explicit realignment. vect_supportable_dr_alignment always returns either @@ -10577,8 +10582,13 @@ vectorizable_load (vec_info *vinfo, ? &LOOP_VINFO_LENS (loop_vinfo) : NULL); - /* Shouldn't go with length-based approach if fully masked. */ - gcc_assert (!loop_lens || !loop_masks); + /* The vect_transform_stmt and vect_analyze_stmt will go here but there + are some difference here. We cannot enable both the lens and masks + during transform but it is allowed during analysis. + Shouldn't go with length-based approach if fully masked. */ + if (cost_vec == NULL) + /* The cost_vec is NULL during transfrom. */ + gcc_assert ((!loop_lens || !loop_masks)); /* Targets with store-lane instructions must not require explicit realignment. vect_supportable_dr_alignment always returns either