From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
	by sourceware.org (Postfix) with ESMTP id 3C2143858C52
	for <gcc-patches@gcc.gnu.org>; Wed, 21 Sep 2022 21:57:54 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C2143858C52
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 28LLureV031798;
	Wed, 21 Sep 2022 16:56:53 -0500
Received: (from segher@localhost)
	by gate.crashing.org (8.14.1/8.14.1/Submit) id 28LLuqRN031797;
	Wed, 21 Sep 2022 16:56:52 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f
Date: Wed, 21 Sep 2022 16:56:52 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: HAO CHEN GUI <guihaoc@linux.ibm.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, David <dje.gcc@gmail.com>,
        "Kewen.Lin" <linkw@linux.ibm.com>,
        Peter Bergner <bergner@linux.ibm.com>
Subject: Re: [PATCH v6, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]
Message-ID: <20220921215652.GG25951@gate.crashing.org>
References: <df790a93-52bf-761a-6586-78d540934f96@linux.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <df790a93-52bf-761a-6586-78d540934f96@linux.ibm.com>
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: <gcc-patches.gcc.gnu.org>

Hi!

On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>   This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
> of smin/max. So the builtins always generate xs[min/max]dp on all
> platforms.

But how does this not blow up with -ffast-math?

In the other direction I am worried that the unspecs will degrade
performance (relative to smin/smax) when -ffast-math *is* active (and
this new builtin code and pattern doesn't blow up).

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 :-)


Segher