From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-405547-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 43752 invoked by alias); 19 Aug 2015 13:41:15 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 43740 invoked by uid 89); 19 Aug 2015 13:41:14 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-io0-f182.google.com
Received: from mail-io0-f182.google.com (HELO mail-io0-f182.google.com) (209.85.223.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 19 Aug 2015 13:41:13 +0000
Received: by iodv127 with SMTP id v127so8922941iod.3        for <gcc-patches@gcc.gnu.org>; Wed, 19 Aug 2015 06:41:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.27.195 with SMTP id b186mr14507518iob.140.1439991671315; Wed, 19 Aug 2015 06:41:11 -0700 (PDT)
Received: by 10.107.16.193 with HTTP; Wed, 19 Aug 2015 06:41:11 -0700 (PDT)
In-Reply-To: <87twrva0ml.fsf@e105548-lin.cambridge.arm.com>
References: <000001d0d5b0$5da4dbb0$18ee9310$@arm.com>	<CAFiYyc1bgWwdV4PRLBuUv3yC0X-k5gJVuyyV9V7Vrz3Lte+wZw@mail.gmail.com>	<000001d0d8cf$2fb42770$8f1c7650$@arm.com>	<CAFiYyc2XT+iqyRNgp+N2gWsaP-=1xVUWsuUEj+bOq_UmE_1eLw@mail.gmail.com>	<000001d0d9a6$1efdc350$5cf949f0$@arm.com>	<CAFiYyc3CLF8beK5GaB86Ad7623gWc9yhc8nTom-ByoaHTEMyOg@mail.gmail.com>	<87fv3gbs36.fsf@e105548-lin.cambridge.arm.com>	<CAFiYyc1q7deng7mjnt788RwqkHuvdDCKW=uWpd=goEvTeZiK5Q@mail.gmail.com>	<8737zfbo2j.fsf@e105548-lin.cambridge.arm.com>	<CAFiYyc1any7rSNCYqEpMDqsCesPte1N=ancreby-XSFBJmJ1Tg@mail.gmail.com>	<87y4h7a35q.fsf@e105548-lin.cambridge.arm.com>	<CAFiYyc2W82jzYE3saLQkNhhDEH1+BFk0yShrh3OVBdjHkkyr3A@mail.gmail.com>	<87twrva0ml.fsf@e105548-lin.cambridge.arm.com>
Date: Wed, 19 Aug 2015 13:41:00 -0000
Message-ID: <CAFiYyc0dt911qOdRAXa3LmcB5JMzPL0jc_Su_0po123Dkp22iA@mail.gmail.com>
Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
From: Richard Biener <richard.guenther@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>, David Sherwood <David.Sherwood@arm.com>, 	GCC Patches <gcc-patches@gcc.gnu.org>, richard.sandiford@arm.com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-08/txt/msg01084.txt.bz2

On Wed, Aug 19, 2015 at 3:06 PM, Richard Sandiford
<richard.sandiford@arm.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> As an additional point for many math functions we have to support errno
>> which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR
>> only if -fno-math-errno is in effect.  But then code has to handle
>> both variants for things like constant folding and expression combining.
>> That's very unfortunate and something we want to avoid (one reason
>> the POW_EXPR thing didn't fly when I tried).  STRICT_FMIN/MAX_EXPR
>> is an example where this doesn't apply, of course (but I detest the name,
>> just use FMIN/FMAX_EXPR?).  Still you'd need to handle both,
>> FMIN_EXPR and BUILT_IN_FMIN, in code doing analysis/transform.
>
> Yeah, but match.pd makes that easy, right? ;-)

Sure, but that only addresses stmt combining, not other passes.  And of course
it causes {gimple,generic}-match.c to become even bigger ;)

Richard.