From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id F09773858D3C for ; Fri, 18 Mar 2022 16:01:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F09773858D3C Received: by mail-pg1-x52c.google.com with SMTP id o23so5352570pgk.13 for ; Fri, 18 Mar 2022 09:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=W/CGE6Po8bwvdTuiGcE389Q1nQ3kB5k25PRjJHkFQ9s=; b=8Nt8qj5StF5mVagjp5ly4jWRVjmWdDd96fkvd+ULI6ZMAmdjrPaOFCN1atVq6Zm9sW ftGdEcfBC4lIaxTJRDJ4I6Wmga/RiYui+45RDlQEpFQDKdP7XAAUGfuyrYQOPLTGMxe6 wII4V4RI5OA+V2RTqNZ3RJlgwwB5FUCqkuVlwmEblQFpE91xrSAa/gpklOSJKe4+4A5o 5c8S8xxPPVV0aIo6dSeFOtRw8pXW5RHsGcttHjgZalq0wbQbKSzpJMEwQMSDH1E6vHwQ u1lzTRka9nfRx3AnwqTK1VuuLILBnn128nnOQlR+9B8BnYo06NLGsO/Jkj7MbIiYIgMH yDEA== X-Gm-Message-State: AOAM5317g/YPxhK54AtoiUe/mt8mI71wzTY9qcG/um6Mzcnb1vR8siwH doENiG1ku2JV3plne/1pQvI= X-Google-Smtp-Source: ABdhPJwcxjqlySaRcFroltHMsr9A4xtjNLYQocM9WDzii86Cc24IYY7Z3Y5aUzIrL/Rxjv8yQWfKzA== X-Received: by 2002:a63:20f:0:b0:378:9f08:a0a4 with SMTP id 15-20020a63020f000000b003789f08a0a4mr8419395pgc.17.1647619310674; Fri, 18 Mar 2022 09:01:50 -0700 (PDT) Received: from [172.31.0.204] (c-73-63-24-84.hsd1.ut.comcast.net. [73.63.24.84]) by smtp.gmail.com with ESMTPSA id k11-20020a056a00168b00b004f7e1555538sm10461613pfc.190.2022.03.18.09.01.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 09:01:49 -0700 (PDT) Message-ID: Date: Fri, 18 Mar 2022 10:01:48 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons. Content-Language: en-US To: Andrew MacLeod , Roger Sayle , 'Richard Biener' , Aldy Hernandez Cc: 'GCC Patches' References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Fri, 18 Mar 2022 16:01:55 -0000 On 3/18/2022 7:16 AM, Andrew MacLeod wrote: > On 3/17/22 19:27, Jeff Law via Gcc-patches wrote: >> >> On 3/15/2022 2:03 AM, Roger Sayle wrote: >>>> -----Original Message----- >>>> From: Richard Biener >>>> Sent: 15 March 2022 07:29 >>>> To: Roger Sayle >>>> Cc: GCC Patches >>>> Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP >>>> comparisons. >>>> >>>> On Mon, Mar 14, 2022 at 8:26 PM Roger Sayle >>>> wrote: >>>>> >>>>> I've been wondering about the possible >>>>> performance/missed-optimization >>>>> impact of my patch for PR middle-end/98420 and similar IEEE >>>>> correctness fixes that disable constant folding optimizations when >>>>> worrying >>>> about -0.0. >>>>> In the common situation where the floating point result is used by a >>>>> FP comparison, there's no distinction between +0.0 and -0.0, so some >>>>> HONOR_SIGNED_ZEROS optimizations that we'd usually disable, are safe. >>>>> >>>>> Consider the following interesting example: >>>>> >>>>> int foo(int x, double y) { >>>>>      return (x * 0.0) < y; >>>>> } >>>>> >>>>> Although we know that x (when converted to double) can't be NaN or >>>>> Inf, we still worry that for negative values of x that (x * 0.0) may >>>>> be -0.0 and so perform the multiplication at run-time. But in this >>>>> case, the result of the comparison (-0.0 < y) will be exactly the >>>>> same >>>>> as (+0.0 < y) for any y, hence the above may be safely constant >>>>> folded to "0.0 < >>>> y" >>>>> avoiding the multiplication at run-time. > > I'm going to hazard a guess that this can be handled in the upcoming > floating point range support?  there was a start of a conversation in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 about a month ago. > > I know *zero* about floating point, but It seems like when we track > floating point ranges, we will naturally be able to integrate > >   _2 = _1 * 0.0; >   _3 = _2 < y_5(D); > > that _2 evaluates to +/- 0.0  and when we do look at  (_2 < y_5)   > that VRP  can simplify that to 0.0 < y?  (or any patch which uses > simplification and ranges).    It seems like it should be > straightforward anyway. Yea, I guess we'd pick it up that way and that's probably cleaner than what I was originally thinking in this space. We realize that 2 is +-0.0.  Then we realize that for the comparison, we can constant propagate +0.0 for _2 since +0.0 and -0.0 behave the same way.  Ideally that removes the last reference to _2 and we DCE away the multiplication. jeff