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 5AAE63858C29 for ; Wed, 31 Jan 2024 16:13:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AAE63858C29 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 5AAE63858C29 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=1706717620; cv=none; b=w2C/0hIHRt0KG87slo9ZlUUTz+ZvN+j43YuZatdQSwC54pAO0MhnbudviMban/8amxDhoxOXHEGj/ib+k0X+P/gjUHUhnXnNmc040tDlxew8v+Sb6RzBST+u5gW1PHVTsVU15ZAEx9sT7Q2eHVw4yLfg5SNies2QONyxiR8Rb7E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706717620; c=relaxed/simple; bh=FEVd7Iawn2UbRDRnpSeRovVktFMDCzDXeFRv3Lbw12A=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=U5Mx7iBYVvI4qL1rbcy/3l37dwmR6bf17IrZJwIY/DlCXZJ+FYqm6jHg8boVThlwAnze1bkAllhAjl4fksEjpIDnCghyxkvU56C+37zo4QJd7i345og2nIXHjcF851118bBRzh6yQukOb7d6AhPDZAP4652DNWsRG3wrBmQTtow= 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 15486DA7; Wed, 31 Jan 2024 08:14:21 -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 2FED73F762; Wed, 31 Jan 2024 08:13:37 -0800 (PST) Message-ID: <2df3c00a-65bd-467a-8c63-3fcf9ad9e586@arm.com> Date: Wed, 31 Jan 2024 16:13:35 +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> <02q2n46q-nr12-q90o-rq2o-10p489q57s46@fhfr.qr> From: "Andre Vieira (lists)" In-Reply-To: <02q2n46q-nr12-q90o-rq2o-10p489q57s46@fhfr.qr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 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 14:03, Richard Biener wrote: > On Wed, 31 Jan 2024, 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? > > Maybe it's just a bit non-obvious as you key on mangling: > > static int > -aarch64_simd_clone_usable (struct cgraph_node *node) > +aarch64_simd_clone_usable (struct cgraph_node *node, stmt_vec_info > stmt_vinfo) > { > switch (node->simdclone->vecsize_mangle) > { > case 'n': > if (!TARGET_SIMD) > return -1; > + if (STMT_VINFO_VECTYPE (stmt_vinfo) > + && aarch64_sve_mode_p (TYPE_MODE (STMT_VINFO_VECTYPE > (stmt_vinfo)))) > + return -1; > > ? What does 'n' mean? It's documented as > > /* The mangling character for a given vector size. This is used > to determine the ISA mangling bit as specified in the Intel > Vector ABI. */ > unsigned char vecsize_mangle; I'll update the comment, but yeh 'n' is for Advanced SIMD, 's' is for SVE. > > which is slightly misleading.