From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id DE2103858400 for ; Thu, 22 Sep 2022 13:57:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE2103858400 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 28MDuhHk000984; Thu, 22 Sep 2022 08:56:43 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 28MDugZX000981; Thu, 22 Sep 2022 08:56:42 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 22 Sep 2022 08:56:42 -0500 From: Segher Boessenkool To: HAO CHEN GUI Cc: "Kewen.Lin" , gcc-patches , David , Peter Bergner Subject: Re: [PATCH v6, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605] Message-ID: <20220922135642.GH25951@gate.crashing.org> References: <20220921215652.GG25951@gate.crashing.org> <2c999590-8222-2879-3fe3-ca69159293ec@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On Thu, Sep 22, 2022 at 05:59:07PM +0800, HAO CHEN GUI wrote: > >> I still think we should get RTL codes for this, to have access to proper > >> floating point min/max semantics always and everywhere. "fmin" and > >> "fmax" seem to be good names :-) > > > > It would be good, especially if we have observed some uses of these bifs > > and further opportunities around them. :) > > > Shall we submit a PR to add fmin/fmax to RTL codes? Yes, please do. If we have fmin/fmax RTL codes that describe the standard semantics, we can generate code for that with -ffast-math as well, since the code generated is optimal in either case; it's just the *generic* optimisations that fall behind. Segher