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 EB80D3858417 for ; Mon, 29 Nov 2021 11:17:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB80D3858417 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 812F11042; Mon, 29 Nov 2021 03:17:40 -0800 (PST) Received: from [10.1.25.138] (E121495.Arm.com [10.1.25.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0A46E3F694; Mon, 29 Nov 2021 03:17:39 -0800 (PST) Message-ID: <1885dad0-3b03-d452-6615-8fed15b273a1@arm.com> Date: Mon, 29 Nov 2021 11:17:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [AArch64] Enable generation of FRINTNZ instructions Content-Language: en-US To: Richard Biener Cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford 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> <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> From: "Andre Vieira (lists)" In-Reply-To: <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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: Mon, 29 Nov 2021 11:17:42 -0000 On 18/11/2021 11:05, Richard Biener wrote: > > + (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. I realized I never responded to this. The AArch64 instructions mimic the behaviour you'd see if you were doing explicit conversions, so I'll be defining the new IFN and optab to require the same, such that these can be used by the compiler when flag_trapping_math. In the patch I sent last I added some likes to the md.texi description of the optab to that intent.