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 080013858406 for ; Thu, 18 Nov 2021 11:05:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 080013858406 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D09022177B; Thu, 18 Nov 2021 11:05:55 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (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 B356EA3B8B; Thu, 18 Nov 2021 11:05:55 +0000 (UTC) Date: Thu, 18 Nov 2021 12:05:55 +0100 (CET) From: Richard Biener To: "Andre Vieira (lists)" cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford Subject: Re: [AArch64] Enable generation of FRINTNZ instructions In-Reply-To: <6c730f35-10b1-2843-cffc-4ed0851380be@arm.com> Message-ID: <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> References: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> <70s9nn94-452-5rrr-4458-q6n3qp563652@fhfr.qr> <36e3469a-3922-d49e-4006-0088eac29157@arm.com> <653o8886-3p5n-sr82-9n83-71q33o8824@fhfr.qr> <6c730f35-10b1-2843-cffc-4ed0851380be@arm.com> MIME-Version: 1.0 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 18 Nov 2021 11:05:59 -0000 On Wed, 17 Nov 2021, Andre Vieira (lists) wrote: > > On 16/11/2021 12:10, Richard Biener wrote: > > On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote: > > > >> On 12/11/2021 10:56, Richard Biener wrote: > >>> On Thu, 11 Nov 2021, Andre Vieira (lists) wrote: > >>> > >>>> Hi, > >>>> > >>>> This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding > >>>> optabs and mappings. It also creates a backend pattern to implement them > >>>> for > >>>> aarch64 and a match.pd pattern to idiom recognize these. > >>>> These IFN's (and optabs) represent a truncation towards zero, as if > >>>> performed > >>>> by first casting it to a signed integer of 32 or 64 bits and then back to > >>>> the > >>>> same floating point type/mode. > >>>> > >>>> The match.pd pattern choses to use these, when supported, regardless of > >>>> trapping math, since these new patterns mimic the original behavior of > >>>> truncating through an integer. > >>>> > >>>> I didn't think any of the existing IFN's represented these. I know it's a > >>>> bit > >>>> late in stage 1, but I thought this might be OK given it's only used by a > >>>> single target and should have very little impact on anything else. > >>>> > >>>> Bootstrapped on aarch64-none-linux. > >>>> > >>>> OK for trunk? > >>> On the RTL side ftrunc32/ftrunc64 would probably be better a conversion > >>> optab (with two modes), so not > >>> > >>> +OPTAB_D (ftrunc32_optab, "ftrunc$asi2") > >>> +OPTAB_D (ftrunc64_optab, "ftrunc$adi2") > >>> > >>> but > >>> > >>> OPTAB_CD (ftrunc_shrt_optab, "ftrunc$a$I$b2") > >>> > >>> or so? I know that gets somewhat awkward for the internal function, > >>> but IMHO we shouldn't tie our hands because of that? > >> I tried doing this originally, but indeed I couldn't find a way to > >> correctly > >> tie the internal function to it. > >> > >> direct_optab_supported_p with multiple types expect those to be of the same > >> mode. I see convert_optab_supported_p does but I don't know how that is > >> used... > >> > >> Any ideas? > > No "nice" ones. The "usual" way is to provide fake arguments that > > specify the type/mode. We could use an integer argument directly > > secifying the mode (then the IL would look host dependent - ugh), > > or specify a constant zero in the intended mode (less visibly > > obvious - but at least with -gimple dumping you'd see the type...). > Hi, > > So I reworked this to have a single optab and IFN. This required a bit of > fiddling with custom expander and supported_p functions for the IFN. I decided > to pass a MAX_INT for the 'int' type to the IFN to be able to pass on the size > of the int we use as an intermediate cast.  I tried 0 first, but gcc was being > too smart and just demoted it to an 'int' for the long long test-cases. > > Bootstrapped on aarch64-none-linux. > > OK for trunk? @@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) trapping behaviour, so require !flag_trapping_math. */ #if GIMPLE (simplify - (float (fix_trunc @0)) - (if (!flag_trapping_math - && types_match (type, TREE_TYPE (@0)) - && direct_internal_fn_supported_p (IFN_TRUNC, type, - OPTIMIZE_FOR_BOTH)) - (IFN_TRUNC @0))) + (float (fix_trunc@1 @0)) + (if (types_match (type, TREE_TYPE (@0))) + (if (TYPE_SIGN (TREE_TYPE (@1)) == SIGNED + && direct_internal_fn_supported_p (IFN_FTRUNC_INT, type, + TREE_TYPE (@1), OPTIMIZE_FOR_BOTH)) + (with { + tree int_type = TREE_TYPE (@1); + unsigned HOST_WIDE_INT max_int_c + = (1ULL << (element_precision (int_type) - 1)) - 1; That's only half-way supporting vector types I fear - you use element_precision but then build a vector integer constant in an unsupported way. I suppose vector support isn't present for arm? The cleanest way would probably be to do tree int_type = element_type (@1); with providing element_type in tree.[ch] like we provide element_precision. + } + (IFN_FTRUNC_INT @0 { build_int_cst (int_type, max_int_c); })) Then you could use wide_int_to_tree (int_type, wi::max_value (TYPE_PRECISION (int_type), SIGNED)) to build the special integer constant (which seems to be always scalar). + (if (!flag_trapping_math + && direct_internal_fn_supported_p (IFN_TRUNC, type, + OPTIMIZE_FOR_BOTH)) + (IFN_TRUNC @0))))) #endif does IFN_FTRUNC_INT preserve the same exceptions as doing explicit intermediate float->int conversions? I think I'd prefer to have !flag_trapping_math on both cases. > gcc/ChangeLog: > >         * config/aarch64/aarch64.md (ftrunc2): New > pattern. >         * config/aarch64/iterators.md (FRINTZ): New iterator. >         * doc/md.texi: New entry for ftrunc pattern name. >         * internal-fn.def (FTRUNC_INT): New IFN. >         * match.pd: Add to the existing TRUNC pattern match. >         * optabs.def (ftrunc_int): New entry. > > gcc/testsuite/ChangeLog: > >         * gcc.target/aarch64/merge_trunc1.c: Adapted to skip if frintNz > instruction available. >         * lib/target-supports.exp: Added arm_v8_5a_frintnzx_ok target. >         * gcc.target/aarch64/frintnz.c: New test. > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)