From patchwork Thu Jun 30 01:40:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew MacLeod X-Patchwork-Id: 1650429 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=FTDS/zK1; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4LYLhB5gPlz9s0r for ; Thu, 30 Jun 2022 11:43:21 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 46F97386CE43 for ; Thu, 30 Jun 2022 01:43:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46F97386CE43 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1656553399; bh=z7IOslFPAbeKkVLeIAu1CSWdFyoHkZABkwP52YMdO7E=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=FTDS/zK1T+YAwg2en4DOwPPzsbSRDcq8B5e/9l6fFSi2cixDe2iBfq+NEKr0zG/uy O7/0/gNgHzcN1mmuejJsKMAmkiX92gNd5o59BLhcIRhPjttp1GEDp68QD6DoEuKwta vInKpfGfoYOZms4vdAlKSRDr1uCYzi1h+9E8F6kQ= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4EE243846456 for ; Thu, 30 Jun 2022 01:42:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4EE243846456 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-RdmPVq6XOCWnIi8Td3aoYQ-1; Wed, 29 Jun 2022 21:42:56 -0400 X-MC-Unique: RdmPVq6XOCWnIi8Td3aoYQ-1 Received: by mail-qk1-f199.google.com with SMTP id bi36-20020a05620a31a400b006a79f0706e5so17926207qkb.2 for ; Wed, 29 Jun 2022 18:42:56 -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 :content-language:to:cc:from:subject; bh=U4oLbhNEPE35G/1tN/74aiJ3XjZclyppmagxDqmt6+0=; b=VTdLAQioHT4vrBV9MhJ260sBZcUxEkTs7yAY98gdKpGNHZmpI+wjOJmM4dwf7rYtbf x5pGYRWDdWT7zVz8c0BtEH0y/KhTlAjil/CgBhUVn2V6E04tHRXH1QtmEAiQbjckBqhJ cZZLVAykKYCLYBFL5LjCcVAMwjhEr116rZwZWS3/279U/F/2bgglS4rVvzenBKYWgKab P9HNr3vCxpxMOwvovDqzVYFIgFV3B0MYu4Qipo7h4Zjc2dWMkUXr5QF1xCkAfYvdhSib C6ohVL/86JPwt8r/6oz+8yxRxp6e1gV10aP6o8wtklhILk/jxbKiU3pjHDDmQonh5bFC ljpA== X-Gm-Message-State: AJIora+C2OaXxSI3LY3JLhbiYnnjFFBlfVk9TEdmx6dcz/+XKFU9ksey 7V+cYHiLhLyLsIqCgNfZ408WEb5TmnonTr72fxxNmdgkLRJ1CGKlQQr4ya1/lsKZ1eRe1r7162v +yxk2uus22jWt0Ai6T8so/GWW6E2CKTkpXzlFR26xb7m6Xs7ajmWfrG/qQIyirDFlOHsAQQ== X-Received: by 2002:a05:620a:27d0:b0:6af:2e15:5c0e with SMTP id i16-20020a05620a27d000b006af2e155c0emr4351736qkp.209.1656553375668; Wed, 29 Jun 2022 18:42:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vrNHSf0ld01qesi5OpH7LhsqEDF2kH+yDTbkcQWBKZjiSL6a99a+pwXH75keO6qpDWkdnzYw== X-Received: by 2002:a05:620a:27d0:b0:6af:2e15:5c0e with SMTP id i16-20020a05620a27d000b006af2e155c0emr4351729qkp.209.1656553375352; Wed, 29 Jun 2022 18:42:55 -0700 (PDT) Received: from [10.0.0.252] (cpea456cc3d0739-cma456cc3d0737.cpe.net.cable.rogers.com. [99.244.104.246]) by smtp.gmail.com with ESMTPSA id bl34-20020a05620a1aa200b006af34a1a897sm7639479qkb.65.2022.06.29.18.42.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jun 2022 18:42:54 -0700 (PDT) Message-ID: Date: Wed, 29 Jun 2022 21:40:44 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 To: gcc-patches Subject: [COMMITTED] PR tree-optimization/106114 - Don't use gori dependencies to optimize. X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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-Patchwork-Original-From: Andrew MacLeod via Gcc-patches From: Andrew MacLeod Reply-To: Andrew MacLeod Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" The routine which tried to fold and's and or's using relations was using the dependency cache as a shortcut to determine if there were 2 ssa names on the feeding expressions, and assuming that was correct. ie   _16 = a.0_1 < -117;   _17 = a.0_1 >= -83;   _18 = _16 | _17; the dependency cache indicates that a.0_1 is "ssa1" dependency for _16 and also for _17.  we dont have to scan the statement, so temporal out of date info is very quick. Its also not meant to reflect that actual statement.. ie, it can get out of date.  Not is a way that makes anything incorrect, but in a way that may possibly result in a  either a missed opportunity or slightly more work when statements are being rewritten on the fly..  ie  DOM rewrites that to:   _16 = a.1_15 < -117;   _17 = a.1_15 >= -83;   _18 = _16 | _17; When fold_using_range is later invoked, a.1_15 is added a dependency to _16 and _17,  not attempting to understand that its a replacement, we simply now think that both a.0_1 and a.1_15 are dependencies.  so if either one becomes out of date, then ranger will recalculate _16 and/or _17 fold_using_range::relation_fold_and_or was using thet dependency cache as if it represent the operands of the statement accurately... so after the DOM rewrite, it thought that there were 2 operands on the _16 and _17 expression, the 2 dependencies in the cache, misconstruing it as   _16 = a.0_1_ < a.1_15;   _17 = a.0_1 >= a.1_15;   _18 = _16 | _17; Thus it thought is could fold it away. The dependency cache shortcut should NOT be used for optimizations.   THis patch correct the problem, and simply looks at the 2 operands of the feeding instructions. bootstrapped on build-x86_64-pc-linux-gnu with no regressions. Pushed. This is less likely to occur in GCC12 since there is less IL change on the fly, but it should be safe to make this change just in case.  OK for GCC12? Andrew PS. and yes, it fixes the other 2 testcases as well. From c11461be4e5f3107d32187f2df9e5d4ec3f7b0d7 Mon Sep 17 00:00:00 2001 From: Andrew MacLeod Date: Wed, 29 Jun 2022 13:34:05 -0400 Subject: [PATCH] Don't use gori depedencies to optimize. The routine fold_using_range::relation_fold_and_or needs to veriyf that both operands of 2 stmts are the same, and uses GORIs dependency cache for this. This cache cannot be counted on to reflect the current contents of a stmt, expecially in the presence of an IL changing pass. Instead, look at the statement operands. PR tree-optimization/106114 gcc/ * gimple-range-fold.cc (fold_using_range::relation_fold_and_or): Check statement operands instead of GORI cache. testsuite/ * gcc.dg/pr106114.c: New. --- gcc/gimple-range-fold.cc | 30 +++++++++++++++++------------- gcc/testsuite/gcc.dg/pr106114.c | 14 ++++++++++++++ 2 files changed, 31 insertions(+), 13 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/pr106114.c diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc index 2a8c66e0c05..0f815b50b9a 100644 --- a/gcc/gimple-range-fold.cc +++ b/gcc/gimple-range-fold.cc @@ -1397,14 +1397,25 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s, // Ideally we search dependencies for common names, and see what pops out. // until then, simply try to resolve direct dependencies. - // Both names will need to have 2 direct dependencies. - tree ssa1_dep2 = src.gori ()->depend2 (ssa1); - tree ssa2_dep2 = src.gori ()->depend2 (ssa2); - if (!ssa1_dep2 || !ssa2_dep2) + gimple *ssa1_stmt = SSA_NAME_DEF_STMT (ssa1); + gimple *ssa2_stmt = SSA_NAME_DEF_STMT (ssa2); + + range_op_handler handler1 (SSA_NAME_DEF_STMT (ssa1)); + range_op_handler handler2 (SSA_NAME_DEF_STMT (ssa2)); + + // If either handler is not present, no relation can be found. + if (!handler1 || !handler2) + return; + + // Both stmts will need to have 2 ssa names in the stmt. + tree ssa1_dep1 = gimple_range_ssa_p (gimple_range_operand1 (ssa1_stmt)); + tree ssa1_dep2 = gimple_range_ssa_p (gimple_range_operand2 (ssa1_stmt)); + tree ssa2_dep1 = gimple_range_ssa_p (gimple_range_operand1 (ssa2_stmt)); + tree ssa2_dep2 = gimple_range_ssa_p (gimple_range_operand2 (ssa2_stmt)); + + if (!ssa1_dep1 || !ssa1_dep2 || !ssa2_dep1 || !ssa2_dep2) return; - tree ssa1_dep1 = src.gori ()->depend1 (ssa1); - tree ssa2_dep1 = src.gori ()->depend1 (ssa2); // Make sure they are the same dependencies, and detect the order of the // relationship. bool reverse_op2 = true; @@ -1413,13 +1424,6 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s, else if (ssa1_dep1 != ssa2_dep2 || ssa1_dep2 != ssa2_dep1) return; - range_op_handler handler1 (SSA_NAME_DEF_STMT (ssa1)); - range_op_handler handler2 (SSA_NAME_DEF_STMT (ssa2)); - - // If either handler is not present, no relation is found. - if (!handler1 || !handler2) - return; - int_range<2> bool_one (boolean_true_node, boolean_true_node); relation_kind relation1 = handler1.op1_op2_relation (bool_one); diff --git a/gcc/testsuite/gcc.dg/pr106114.c b/gcc/testsuite/gcc.dg/pr106114.c new file mode 100644 index 00000000000..64c8b8d390a --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr106114.c @@ -0,0 +1,14 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-dom2" } */ + +int printf(const char *, ...); +char a = 139, b; +int main() { + char c = 173; + b = a; + while (c <= a || a < -117) + c = printf("0\n"); + return 0; +} + +/* { dg-final { scan-tree-dump-times "if" 2 "dom2" } } */ -- 2.17.2