From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81287 invoked by alias); 7 May 2019 11:50:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 81278 invoked by uid 89); 7 May 2019 11:50:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*R:D*gcc.gnu.org, H*R:D*gnu.org, HX-Languages-Length:1672, passthrough X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 May 2019 11:50:51 +0000 Received: from grove.saclay.inria.fr ([193.55.177.244]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2019 13:50:28 +0200 Date: Tue, 07 May 2019 11:50:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: Jakub Jelinek cc: Richard Biener , Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fold (x + 0.0) + 0.0 to x + 0.0 (PR tree-optimization/90356) In-Reply-To: <20190507091147.GJ2706@tucnak> Message-ID: References: <20190507072146.GG2706@tucnak> <20190507075521.GH2706@tucnak> <20190507091147.GJ2706@tucnak> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2019-05/txt/msg00289.txt.bz2 On Tue, 7 May 2019, Jakub Jelinek wrote: > On Tue, May 07, 2019 at 09:55:21AM +0200, Jakub Jelinek wrote: >> On Tue, May 07, 2019 at 09:48:13AM +0200, Richard Biener wrote: >>> Will leave the "correctness check" for other folks >>> but the above is > > BTW, as I wanted to be sure about the correctness, I wrote a simple program > (below). Good idea :-) > And actually it seems that we could optimize the plus1 == plus2 cases > even if HONOR_SIGN_DEPENDENT_ROUNDING (type), because even in fesetenv > (FE_DOWNWARD) mode the testcase prints the first two (in all other modes all > 4). It is very hard to judge what is ok with -frounding-math, because that mode is already unusably broken (I use a pass-through asm volatile to protect the arguments and result of every operation instead). One important aspect of the optimization is whether both operations use the same rounding mode, or if there may be a call to fesetround in between. Probably we shouldn't care about -frounding-mode, since anyway it is likely that it will use some IFN_FANCY_PLUS instead of PLUS_EXPR if it is ever implemented. > + (inner_op @0 @1)))))))) Shouldn't you give it a name in the source pattern and return that, instead of creating a new statement? Or are you doing the operation a second time on purpose in case the rounding mode changed or to force an exception? > + (outer_op @0 @2) With sNaN, this may raise a second exception where we used to have only qNaN+0, no? And the handling of exceptions may have changed in between, etc. Yes, -ftrapping-math is just as broken as -frounding-math. -- Marc Glisse