From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 147653858D20 for ; Tue, 15 Mar 2022 10:50:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 147653858D20 Received: by mail-ed1-x530.google.com with SMTP id b15so19524341edn.4 for ; Tue, 15 Mar 2022 03:50: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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EHscAnRkP+ZA8Tb31ka3VqBZsu6LaYDa4iuDGfmcdBQ=; b=ogJN9SEPM//kC50MKNq3ZsM4yINg4/I++d5aJJCC4SezQTflKU096t/7QEtz55SUxu ed4+MT1D+QYSp5z3cpS2jVb4rnrGgzuPlfHvu16TEKLnjRA4Oi6PyDkfePo8We0i/prY 8WUasJIGjl8n7HB1qTJKSqUpclmuxKz1QVZzkBP7DszXDtYKnztqpV10iivKNun3xsKT Kazlxor2NIGecwhJdUF8tkwLwuaJtZn2Zqlnc9cJVIeherFEWLk0hK4BIGCxoIRnbkYO R4a9pQe36r9yo7fLhqr5vlsHqYULipROX3yguETyVtLVQ3XEAPdfHiXYlQkdoSVBECKy qYgA== X-Gm-Message-State: AOAM530DM8PO1SDePFTuYq5AxYE7XzrZ0TkbYlMf622+KGAN74S5mTse UhuqylmS2BJoly0ZaNKUgA49hlk8EXSkqeWTawU= X-Google-Smtp-Source: ABdhPJwv8TnD8bgi3swTBxI1uUqWLn50PsQG9Au3CKc4Pp3I62fBstnu0n3I1Svl3NoQ+374tYGc+AN4XTfVAF4LbOg= X-Received: by 2002:a05:6402:3719:b0:412:fc6b:f271 with SMTP id ek25-20020a056402371900b00412fc6bf271mr24248898edb.345.1647341438518; Tue, 15 Mar 2022 03:50:38 -0700 (PDT) MIME-Version: 1.0 References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> In-Reply-To: <009701d83843$26293a30$727bae90$@nextmovesoftware.com> From: Richard Biener Date: Tue, 15 Mar 2022 11:50:27 +0100 Message-ID: Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons. To: Roger Sayle Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, 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: Tue, 15 Mar 2022 10:50:42 -0000 On Tue, Mar 15, 2022 at 9: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? Probably not. > 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? The only reason would be to avoid growing match.pd with lots of special patterns for cases that should rarely matter in practice. For example the pattern at hand wouldn't trigger for (x * 0.0) * z < y which is why I thought of backprop. Yes, we do have match.pd patterns with similar issues already. Basically when the pattern doesn't simplify the outermost expression it is prone to such issues. > 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. There's a few other pieces in the patch (didn't look at it before), changing HONOR_NANS and ltgt, those are OK independently. One comment, instead of matching both (cmp (mult ...) @2) and (cmp @2 (mult ..)) you can use :c on the 'cmp' - it will do the "right" thing (swap the comparison code) when matching the other way around. That will reduce repetition. > > 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've left this to the ranger folks - you may want to ping Andrew here. Richard. > Thanks (as always), > Roger > > > Thanks, > > Richard. > > > > > > > > 2022-03-14 Roger Sayle > > > > > > gcc/ChangeLog > > > * match.pd (X CMP (Y-Y) -> X CMP 0.0): New transformation. > > > (X CMP (Y * 0.0) -> X CMP 0.0): Likewise. > > > (X CMP X -> true): Test tree_expr_maybe_nan_p instead of > > HONOR_NANS. > > > (X LTGT X -> false): Enable if X is not tree_expr_maybe_nan_p, as > > > this can't trap/signal. > > > > > > gcc/testsuite/ChangeLog > > > * gcc.dg/fold-compare-9.c: New test case. > > > > > > > > > Thanks in advance, > > > Roger > > > -- > > > >