From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1A9673858C55 for ; Fri, 19 Aug 2022 08:03:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A9673858C55 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6157523A; Fri, 19 Aug 2022 01:03:42 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 057C43F70D; Fri, 19 Aug 2022 01:03:39 -0700 (PDT) From: Richard Sandiford To: juzhe.zhong@rivai.ai Mail-Followup-To: juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org, rguenther@suse.de, kito.cheng@gmail.com, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, rguenther@suse.de, kito.cheng@gmail.com Subject: Re: [PATCH] middle-end: skipp stepped vector test of poly_int (1, 1) and allow the machine_mode definition with poly_uint16 (1, 1) References: <20220818104608.259204-1-juzhe.zhong@rivai.ai> Date: Fri, 19 Aug 2022 09:03:38 +0100 In-Reply-To: <20220818104608.259204-1-juzhe.zhong@rivai.ai> (juzhe zhong's message of "Thu, 18 Aug 2022 18:46:08 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-51.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, 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: , X-List-Received-Date: Fri, 19 Aug 2022 08:03:44 -0000 juzhe.zhong@rivai.ai writes: > 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); I think instead we should use maybe_gt (nunits, 1), on the basis that the fore_back tests require vectors that have a minimum of 2 elements. Something like poly_uint16 (1, 2) would have the same problem as poly_uint16 (1, 1). ({1, 2} is an unlikely value, but it's OK in principle.) This corresponds to the minimum of 3 elements for the stepped tests: if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT && maybe_gt (GET_MODE_NUNITS (mode), 2)) { test_vector_ops_series (mode, scalar_reg); test_vector_subregs (mode); } Thanks, Richard