From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id DB81B3858402 for ; Fri, 12 Nov 2021 10:56:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB81B3858402 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C766F1FD5B; Fri, 12 Nov 2021 10:56:05 +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 C1627A3B8B; Fri, 12 Nov 2021 10:56:05 +0000 (UTC) Date: Fri, 12 Nov 2021 11:56:05 +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: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> Message-ID: <70s9nn94-452-5rrr-4458-q6n3qp563652@fhfr.qr> References: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> MIME-Version: 1.0 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, 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=ISO-8859-15 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: Fri, 12 Nov 2021 10:56:08 -0000 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? Richard. > 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 (FTRUNC32): New IFN. >         (FTRUNC64): Likewise. >         * match.pd: Add to the existing TRUNC pattern match. >         * optabs.def (OPTAB_D): New entries for ftrunc. > > 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)