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 E39BD3858C54 for ; Mon, 26 Feb 2024 16:56:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E39BD3858C54 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 E39BD3858C54 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=1708966587; cv=none; b=SqNHwoLo4KaH20lKS0SoSiHOril0emcCbQOTXVrerLKnPern8EYDZVwKAKoz/5WAU82dEnALb8UfoHCM/oq2mxnYTM6v2FUZTxHoi+KVxA26u/QXZ8QP7o29I1cLpZtPft0ytYLD9cw2iZ+Qr8G5g9UG0isi5n6Lmx8A7wd2lrc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708966587; c=relaxed/simple; bh=tU9bysrHYbJX2RxWN2/rmo2QjnIyBqSrpV/wmVcL3qg=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=X6Qq6N9YkoB36nvUrNhwC5T6w7nxSltYf/86XOdq17lMmvm5/+sOn4K8vsKEH1gtuhyNgs3/CwOn4Ytrod7cp+GdBv6vWwrgbl3X7CeDyJF+FXttMrogk0qgjLdoKl9Bo0fl3XfKYOfHyCDfjfTRO3zaYLPjrm43eB1OKLCaSss= 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 3C30CDA7; Mon, 26 Feb 2024 08:57:04 -0800 (PST) Received: from [10.57.66.110] (unknown [10.57.66.110]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1A7013F73F; Mon, 26 Feb 2024 08:56:24 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2024 16:56:20 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE 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> <3rq8sn71-8188-o4rq-9spp-q9spn98163q5@fhfr.qr> <359e8112-65c9-40b1-9566-aa31165c05e8@arm.com> Content-Language: en-US From: "Andre Vieira (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.8 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 05/02/2024 09:56, Richard Biener wrote: > On Thu, 1 Feb 2024, Andre Vieira (lists) wrote: > >> >> >> On 01/02/2024 07:19, Richard Biener wrote: >>> On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: >>> >>> >>> The patch didn't come with a testcase so it's really hard to tell >>> what goes wrong now and how it is fixed ... >> >> My bad! I had a testcase locally but never added it... >> >> However... now I look at it and ran it past Richard S, the codegen isn't >> 'wrong', but it does have the potential to lead to some pretty slow codegen, >> especially for inbranch simdclones where it transforms the SVE predicate into >> an Advanced SIMD vector by inserting the elements one at a time... >> >> An example of which can be seen if you do: >> >> gcc -O3 -march=armv8-a+sve -msve-vector-bits=128 -fopenmp-simd t.c -S >> >> with the following t.c: >> #pragma omp declare simd simdlen(4) inbranch >> int __attribute__ ((const)) fn5(int); >> >> void fn4 (int *a, int *b, int n) >> { >> for (int i = 0; i < n; ++i) >> b[i] = fn5(a[i]); >> } >> >> Now I do have to say, for our main usecase of libmvec we won't have any >> 'inbranch' Advanced SIMD clones, so we avoid that issue... But of course that >> doesn't mean user-code will. > > It seems to use SVE masks with vector(4) and the > ABI says the mask is vector(4) int. You say that's because we choose > a Adv SIMD clone for the SVE VLS vector code (it calls _ZGVnM4v_fn5). > > The vectorizer creates > > _44 = VEC_COND_EXPR ; > > and then vector lowering decomposes this. That means the vectorizer > lacks a check that the target handles this VEC_COND_EXPR. > > Of course I would expect that SVE with VLS vectors is able to > code generate this operation, so it's missing patterns in the end. > > Richard. > What should we do for GCC-14? Going forward I think the right thing to do is to add these patterns. But I am not even going to try to do that right now and even though we can codegen for this, the result doesn't feel like it would ever be profitable which means I'd rather not vectorize, or well pick a different vector mode if possible. This would be achieved with the change to the targethook. If I change the hook to take modes, using STMT_VINFO_VECTYPE (stmt_vinfo), is that OK for now? Kind regards, Andre