From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 146403858413 for ; Thu, 17 Mar 2022 23:27:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 146403858413 Received: by mail-pf1-x42b.google.com with SMTP id z16so8118995pfh.3 for ; Thu, 17 Mar 2022 16:27:40 -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=AhN6rI0ACEkUZZ+5Ak2p6+kSzWlJ/fnUBa9n0MceBJE=; b=ubOGbNxnkpHuVuS+myrFWtSr484YlrYg4ARmffSoMBBGJKGl79byDJH6/Hui128vhh 8S9d42d/vRgYYHUdLHsUz5xbZkCMkMxrXl7MN/sfk2A3BSRBdDA4sUkwNeizrG/irEwz FrvBtK5W46F92+mhEX5wTLk+a/89Zq6tdg8oVMxmj/+bTqbPFZ9pgfmUGrsepqiFBn7p U4982b+36LKHts1XQXDUH7B0hPqxq4OF9GO5FsBybNun5CKIFVAyA8CHw7znyJYS0ssq CAd7fOETKUN0AnaSKKWINiLcqCnP4TVuCdgYXAxYs6yu1JBO6rv7VQ7Y6uId0aDIw/8s /QJQ== X-Gm-Message-State: AOAM530pYbSSfJipnUiQspLTjRf4z5ALN0TRWqLQGjz5LC/FGGpUY9Ii cIOTlcbN5kUZyEt/VsYaen8= X-Google-Smtp-Source: ABdhPJz3/Jf7RSkwyPQvzJgrQWE70FEMLrhrlkb88j87HdWJkYg+KnKZNZbWp+DV2NcRlGLPN1KqPA== X-Received: by 2002:a63:7502:0:b0:37f:f089:7d56 with SMTP id q2-20020a637502000000b0037ff0897d56mr5591251pgc.531.1647559658914; Thu, 17 Mar 2022 16:27:38 -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 132-20020a62168a000000b004f40e8b3133sm8139778pfw.188.2022.03.17.16.27.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Mar 2022 16:27:38 -0700 (PDT) Message-ID: Date: Thu, 17 Mar 2022 17:27:37 -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: Roger Sayle , 'Richard Biener' Cc: 'GCC Patches' References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> From: Jeff Law In-Reply-To: <009701d83843$26293a30$727bae90$@nextmovesoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, 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: Thu, 17 Mar 2022 23:27:42 -0000 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. >>> >>> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap >>> and make -k check with no new failures, and allows GCC to continue to >>> optimize cases that we optimized in GCC 11 (without regard to correctness). >>> Ok for mainline? >> Isn't that something that gimple-ssa-backprop.c is designed to handle? I wonder >> if you can see whether the signed zero speciality can be retrofitted there? >> It currently tracks "sign does not matter", so possibly another state, "sign of >> zero does not matter" could be introduced there. > Two questions. Would adding tracking of "sign of zero does not matter" to > gimple-ssa-backprop.c be suitable for stage4? Secondly, even if gimple-ssa-backprop.c > performed this kind of optimization, would that be a reason not to support > these transformations in match.pd? Perhaps someone could open a missed > optimization PR for backprop in Bugzilla, but the above patch still needs to be > reviewed on its own merits. Can't see how it's appropriate for stage4, but definitely interesting for gcc-13. It'd fit well into some of the Ranger plans too -- Aldy and Andrew have been talking about tracking the special FP values in Ranger.   This is related, though not exactly the same since rather than tracking the special value, you're tracking if those special values actually matter.  If you're going to do more work in this space, you might want to reach out to Aldy and Andrew to see if there's space for collaboration. > > Speaking of tree-ssa passes that could be improved, I was wondering whether > you could review my EVRP patch to fix regression PR/102950. Pretty please? > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589569.html I forwarded this to Aldy & Andrew.  I suspect they missed it. > > Thanks (as always), No, thank you.  I'm so happy to see you contributing to GCC regularly again! Jeff >