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 B58F83858434 for ; Wed, 31 Jan 2024 14:35:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B58F83858434 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B58F83858434 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706711752; cv=none; b=N2u2tCLTdGd02JdQifh0NQsGMA19JW0LEzOoF+8tdqc4mZrwe4Wtli+GlRsvUynjTrFKFH+NcjGpgEaDwJD2jSvwzlPAvWJEIv5uvMjK9iy46kyiqtd+5VRN6m+SGXa9LoTRe+wni+nCRgNeopXspTZ1cOB2qC0tia/Pkq1LYs8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706711752; c=relaxed/simple; bh=WXC1yCeSwYxWIg2hyjGZhldiEmKhU4HTYNMBTVRuMdE=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=JHKYTJjjov6GlL19Ofywy3u3VXans+Np8iV9CRkpPiR1LLgv+X7tHPpeqEz8CW1w9f1eh7ooVSPgm13Hx7KWbt1ODGLxn9GdfGAGOcH2CRZpz7UNMMZv5z6Sej20zHgt5XppbQ7PVKeZoxAgeAO6Urkr7PHUUU5TDjmplNCplD0= ARC-Authentication-Results: i=1; server2.sourceware.org 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 B8C9ADA7; Wed, 31 Jan 2024 06:36:33 -0800 (PST) Received: from [10.57.78.243] (unknown [10.57.78.243]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D480C3F738; Wed, 31 Jan 2024 06:35:49 -0800 (PST) Message-ID: Date: Wed, 31 Jan 2024 14:35:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE Content-Language: en-US To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Richard.Sandiford@arm.com References: <20240130143132.9575-1-andre.simoesdiasvieira@arm.com> <20240130143132.9575-2-andre.simoesdiasvieira@arm.com> <47e1aeb2-94ac-4733-b49f-ea97932cc49f@arm.com> <545r8s73-675p-4o48-sr66-q6956nqp6r6p@fhfr.qr> From: "Andre Vieira (lists)" In-Reply-To: <545r8s73-675p-4o48-sr66-q6956nqp6r6p@fhfr.qr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 31/01/2024 13:58, Richard Biener wrote: > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > >> >> >> On 31/01/2024 12:13, Richard Biener wrote: >>> On Wed, 31 Jan 2024, Richard Biener wrote: >>> >>>> On Tue, 30 Jan 2024, Andre Vieira wrote: >>>> >>>>> >>>>> This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the >>>>> target can reject a simd_clone based on the vector mode it is using. >>>>> This is needed because for VLS SVE vectorization the vectorizer accepts >>>>> Advanced SIMD simd clones when vectorizing using SVE types because the >>>>> simdlens >>>>> might match. This will cause type errors later on. >>>>> >>>>> Other targets do not currently need to use this argument. >>>> >>>> Can you instead pass down the mode? >>> >>> Thinking about that again the cgraph_simd_clone info in the clone >>> should have sufficient information to disambiguate. If it doesn't >>> then we should amend it. >>> >>> Richard. >> >> Hi Richard, >> >> Thanks for the review, I don't think cgraph_simd_clone_info is the right place >> to pass down this information, since this is information about the caller >> rather than the simdclone itself. What we are trying to achieve here is making >> the vectorizer being able to accept or reject simdclones based on the ISA we >> are vectorizing for. To distinguish between SVE and Advanced SIMD ISAs we use >> modes, I am also not sure that's ideal but it is what we currently use. So to >> answer your earlier question, yes I can also pass down mode if that's >> preferable. > > Note cgraph_simd_clone_info has simdlen and we seem to check elsewhere > whether that's POLY or constant. I wonder how aarch64_sve_mode_p > comes into play here which in the end classifies VLS SVE modes as > non-SVE? > Using -msve-vector-bits=128 (gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo)) $4 = E_VNx4SImode (gdb) p TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo)) $5 = (tree) 0xfffff741c1b0 (gdb) p debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo))) 128 (gdb) p aarch64_sve_mode_p (TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo))) $5 = true and for reference without vls codegen: (gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo)) $1 = E_VNx4SImode (gdb) p debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo))) POLY_INT_CST [128, 128] Having said that I believe that the USABLE targethook implementation for aarch64 should also block other uses, like an Advanced SIMD mode being used as input for a SVE VLS SIMDCLONE. The reason being that for instance 'half' registers like VNx2SI are packed differently from V2SI. We could teach the vectorizer to support these of course, but that requires more work and is not extremely useful just yet. I'll add the extra check that to the patch once we agree on how to pass down the information we need. Happy to use either mode, or stmt_vec_info and extract the mode from it like it does now. >> Regards, >> Andre >> >