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 1A9683858430 for ; Tue, 16 Nov 2021 12:10:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A9683858430 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 0AA451FD26; Tue, 16 Nov 2021 12:10:37 +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 0232EA3B85; Tue, 16 Nov 2021 12:10:36 +0000 (UTC) Date: Tue, 16 Nov 2021 13:10:36 +0100 (CET) From: Richard Biener To: Andre Simoes Dias Vieira cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford Subject: Re: [AArch64] Enable generation of FRINTNZ instructions In-Reply-To: <36e3469a-3922-d49e-4006-0088eac29157@arm.com> Message-ID: <653o8886-3p5n-sr82-9n83-71q33o8824@fhfr.qr> References: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> <70s9nn94-452-5rrr-4458-q6n3qp563652@fhfr.qr> <36e3469a-3922-d49e-4006-0088eac29157@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 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: Tue, 16 Nov 2021 12:10:39 -0000 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...). In any case if people think going with two optabs is OK then please consider using ftruncsi and ftruncdi instead of 32/64. Richard.