From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 02E6A3858C83 for ; Mon, 26 Sep 2022 08:26:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02E6A3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id CF98422093; Mon, 26 Sep 2022 08:26:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1664180804; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uEPgCdKejWYIKVzLVZZQAVAt6d2qIGxn5oQKrSGKRwU=; b=CUoTUZme4IT5MkhXElLSLBPelYUoV0/M2xtt9MXv5o8ndfRphV7qHM5IyiYgwpSDmdgF65 QxOs2CrZNUsfERJGn9QjZZ+Bs3gSDZ5jfIKh+vNECqx0VdpEM3DgbnIwKf+j7V79OplnSS VTyRpUcsvKmedoU/Mm9Yeym4Lm+8OlE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1664180804; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uEPgCdKejWYIKVzLVZZQAVAt6d2qIGxn5oQKrSGKRwU=; b=l8mTBroQNNDsB92Wx8jz0kK3e5Ty51EBf/J/cOkBrwoRZQMbd5QhhOcgDENPgYZ/7urYHu rvBtMiKvLtgqLBDQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id AEE912C14B; Mon, 26 Sep 2022 08:26:44 +0000 (UTC) Date: Mon, 26 Sep 2022 08:26:44 +0000 (UTC) From: Richard Biener To: Richard Sandiford cc: Tamar Christina , "gcc-patches@gcc.gnu.org" , nd , Richard Earnshaw , Marcus Shawcroft , Kyrylo Tkachov Subject: Re: [PATCH 2/2]AArch64 Add support for neg on v1df In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Fri, 23 Sep 2022, Richard Sandiford wrote: > Tamar Christina writes: > >> -----Original Message----- > >> From: Richard Sandiford > >> Sent: Friday, September 23, 2022 6:04 AM > >> To: Tamar Christina > >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > >> ; Marcus Shawcroft > >> ; Kyrylo Tkachov > >> Subject: Re: [PATCH 2/2]AArch64 Add support for neg on v1df > >> > >> Tamar Christina writes: > >> >> -----Original Message----- > >> >> From: Richard Sandiford > >> >> Sent: Friday, September 23, 2022 5:30 AM > >> >> To: Tamar Christina > >> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > >> >> ; Marcus Shawcroft > >> >> ; Kyrylo Tkachov > >> > >> >> Subject: Re: [PATCH 2/2]AArch64 Add support for neg on v1df > >> >> > >> >> Tamar Christina writes: > >> >> > Hi All, > >> >> > > >> >> > This adds support for using scalar fneg on the V1DF type. > >> >> > > >> >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> >> > > >> >> > Ok for master? > >> >> > >> >> Why just this one operation though? Couldn't we extend iterators > >> >> like > >> >> GPF_F16 to include V1DF, avoiding the need for new patterns? > >> >> > >> > > >> > Simply because it's the only one I know how to generate code for. > >> > I can change GPF_F16 but I don't know under which circumstances we'd > >> > generate a V1DF for the other operations. > >> > >> We'd do it for things like: > >> > >> __Float64x1_t foo (__Float64x1_t x) { return -x; } > >> > >> if the pattern is available, instead of using subregs. So one way would be to > >> scan the expand rtl dump for subregs. > > > > Ahh yes, I forgot about that ACLE type. > > > >> > >> If the point is that there is no observable difference between defining 1- > >> element vector ops and not, except for this one case, then that suggests we > >> should handle this case in target-independent code instead. There's no point > >> forcing every target that has V1DF to define a duplicate of the DF neg > >> pattern. > > > > My original approach was to indeed use DF instead of V1DF, however since we > > do define V1DF I had expected the mode to be somewhat usable. > > > > So I'm happy to do whichever one you prefer now that I know how to test it. > > I can either change my mid-end code, or extend the coverage of V1DF, any preference? ? > > I don't mind really, as long as we're consistent. Maybe Richi has an opinion. > > If he doesn't mind either, then I guess it makes sense to define the ops > as completely as possible (e.g. equivalently to V2SF), although it doesn't > need to be all in one go. I don't mind either, we'll see if theres a target vector registers not overlapping FP regisers at some point, then it probably matters so it does seem we should support both variants from the middle-end at least. If we have some noop-conversion target hook that tells us this RTL expansion could use a fallback generating subregs for V1mode modes. Richard. > Thanks, > Richard > > > Tamar > > > >> > >> Thanks, > >> Richard > >> > > >> > So if it's ok to do so without full test coverage I'm happy to do so... > >> > > >> > Tamar. > >> > > >> >> Richard > >> >> > >> >> > > >> >> > Thanks, > >> >> > Tamar > >> >> > > >> >> > gcc/ChangeLog: > >> >> > > >> >> > * config/aarch64/aarch64-simd.md (negv1df2): New. > >> >> > > >> >> > gcc/testsuite/ChangeLog: > >> >> > > >> >> > * gcc.target/aarch64/simd/addsub_2.c: New test. > >> >> > > >> >> > --- inline copy of patch -- > >> >> > diff --git a/gcc/config/aarch64/aarch64-simd.md > >> >> > b/gcc/config/aarch64/aarch64-simd.md > >> >> > index > >> >> > > >> >> > >> f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 > >> >> b8 > >> >> > e6be0d56101f 100644 > >> >> > --- a/gcc/config/aarch64/aarch64-simd.md > >> >> > +++ b/gcc/config/aarch64/aarch64-simd.md > >> >> > @@ -2713,6 +2713,14 @@ (define_insn "neg2" > >> >> > [(set_attr "type" "neon_fp_neg_")] > >> >> > ) > >> >> > > >> >> > +(define_insn "negv1df2" > >> >> > + [(set (match_operand:V1DF 0 "register_operand" "=w") > >> >> > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] > >> >> > +"TARGET_SIMD" > >> >> > + "fneg\\t%d0, %d1" > >> >> > + [(set_attr "type" "neon_fp_neg_d")] > >> >> > +) > >> >> > + > >> >> > (define_insn "abs2" > >> >> > [(set (match_operand:VHSDF 0 "register_operand" "=w") > >> >> > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" > >> >> > "w")))] diff --git > >> >> > a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > new file mode 100644 > >> >> > index > >> >> > > >> >> > >> 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 > >> >> e0 > >> >> > f516974f7ca8 > >> >> > --- /dev/null > >> >> > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > @@ -0,0 +1,22 @@ > >> >> > +/* { dg-do compile } */ > >> >> > +/* { dg-options "-Ofast" } */ > >> >> > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } > >> >> > +} } */ > >> >> > + > >> >> > +#pragma GCC target "+nosve" > >> >> > + > >> >> > +/* > >> >> > +** f1: > >> >> > +** ... > >> >> > +** fneg d[0-9]+, d[0-9]+ > >> >> > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s > >> >> > +** ... > >> >> > +*/ > >> >> > +void f1 (float *restrict a, float *restrict b, float *res, int n) { > >> >> > + for (int i = 0; i < 2; i+=2) > >> >> > + { > >> >> > + res[i+0] = a[i+0] + b[i+0]; > >> >> > + res[i+1] = a[i+1] - b[i+1]; > >> >> > + } > >> >> > +} > >> >> > + > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)