From patchwork Thu Aug 18 10:46:08 2022 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: 1667640 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 4M7hQT0LJXz1ygd for ; Thu, 18 Aug 2022 20:46:39 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0DD0B385841D for ; Thu, 18 Aug 2022 10:46:37 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) by sourceware.org (Postfix) with ESMTPS id A4B373858D28 for ; Thu, 18 Aug 2022 10:46:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4B373858D28 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: bizesmtp82t1660819573t0n7blfl Received: from server1.localdomain ( [42.247.22.65]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 18 Aug 2022 18:46:11 +0800 (CST) X-QQ-SSF: 01400000002000C0I000B00A0000000 X-QQ-FEAT: hoArX50alxFw51gJ2QF40dBdk3RJy1IHjicOZ1ImaSbPe8pRZSgWOOhz4opHE JyeXSnhCg5D5QDbiNU67DVeQ06HcDJK++eGraQgE1l8ZPWosz/E//iSgwGKtAyIgX+txnOp ElaCBJKZHwyf6FSiPtsGLApenpf+p1aGt2Thw5qDyhOyL1eM7C5GcqrrFUzm65BBjO8SLPH 6X6llE9Qx7ucEdayLI6VfJSK2QQSUmMBsKhDcj4vzNr5wiJ+UGgNLACaL496vYXRE2nWOXQ htdLvRQTM2UIF3XQZAle1brRQ0VZfOeNXgb0cO7YCRxpD08o0u9gcUhEecDH7XT8SX5BGIZ cBPZV88VltkoXXDEo9FbEzsmwsHM9IKLweGAleHFJA8mXxaTtKvjZMJa4ECIW4LXB7q8Z30 CmjVeAFL37Q= X-QQ-GoodBg: 2 From: juzhe.zhong@rivai.ai To: gcc-patches@gcc.gnu.org Subject: [PATCH] middle-end: skipp stepped vector test of poly_int (1, 1) and allow the machine_mode definition with poly_uint16 (1, 1) Date: Thu, 18 Aug 2022 18:46:08 +0800 Message-Id: <20220818104608.259204-1-juzhe.zhong@rivai.ai> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvr:qybglogicsvr7 X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_HELO_TEMPERROR 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: , Cc: richard.sandiford@arm.com, rguenther@suse.de, kito.cheng@gmail.com, zhongjuzhe Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" From: zhongjuzhe Hello. This patch is preparing for following RVV support. Both ARM SVE and RVV (RISC-V 'V' Extension) support length-agnostic vector. The minimum vector length of ARM SVE is 128-bit and the runtime invariant of ARM SVE is always 128-bit blocks. However, the minimum vector length of RVV can be 32bit in 'Zve32*' sub-extension and 64bit in 'Zve*' sub-extension. So I define the machine_mode as follows: VECTOR_MODE_WITH_PREFIX (VNx, INT, DI, 1, 0); ADJUST_NUNITS (MODE, riscv_vector_chunks); The riscv_vector_chunks = poly_uint16 (1, 1) The compilation is failed for the stepped vector test: (const_vector:VNx1DI repeat [ (const_int 8 [0x8]) (const_int 7 [0x7]) ]) I understand for stepped vector should always have aleast 2 elements and stepped vector initialization is common for VLA (vector-lengthe agnostic) auto-vectorization. It makes sense that report fail for stepped vector of poly_uint16 (1, 1). machine mode with nunits = poly_uint16 (1, 1) needs to implemented in intrinsics. And I would like to enable RVV auto-vectorization with vector mode only nunits is larger than poly_uint16 (2, 2) in RISC-V backend. I think it will not create issue if we define vector mode with nunits = poly_uint16 (1, 1). Feel free to correct me or offer me some other better solutions. Thanks! gcc/ChangeLog: * simplify-rtx.cc (test_vector_subregs_fore_back): skip test for poly_uint16 (1, 1). --- gcc/simplify-rtx.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index 7d09bf7103d..61e0dfa00d0 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -8438,7 +8438,7 @@ test_vector_subregs_fore_back (machine_mode inner_mode) rtx x = builder.build (); test_vector_subregs_modes (x); - if (!nunits.is_constant ()) + if (!nunits.is_constant () && known_ne (nunits, poly_uint16 (1, 1))) test_vector_subregs_modes (x, nunits - min_nunits, count); }