From patchwork Fri Sep 30 23:32:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1617 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp31609wrs; Fri, 30 Sep 2022 16:33:16 -0700 (PDT) X-Google-Smtp-Source: AMsMyM76KYMVJ/TT9aj/ujz182Hb+SHq9s+yjWUAPGcC8ax5evEP9vA3I5t9J1dpjkYfVZl1GcgC X-Received: by 2002:a17:907:6e1d:b0:781:f24f:4bb with SMTP id sd29-20020a1709076e1d00b00781f24f04bbmr8002635ejc.712.1664580796225; Fri, 30 Sep 2022 16:33:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664580796; cv=none; d=google.com; s=arc-20160816; b=iZsBYPJjCCuYwVqss095RBqfKf89GLj7BQ5QbTydq8TdyezWSUs2ziz4m4Oz69SNXp MWnhLKIqE0PqdZ1LpJFCEaMrvX8y71djxfQhbf9kSIyjOTTfH2buz+zV3rUrTmxu1y/z hPMABYdBqBzISTvrZ2WepJDXYkgM7uQDArH42DjhDLz/xvOZt5Hc3OzKH+6uM6qdKGCt MYuN/JQ/ZNEf+RASojpditPVDQBv1ycBHrMKHgVVcSuK3X6EXDY785FH1HVL4lXzDyIn SH+0zskzEtdLPEEytge1DWRvueclFNdaRXuidg6eD8fmoT/GHiJSJP/0FVCAvSFrykEc RQng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject:from:to :content-language:user-agent:mime-version:date:message-id :dkim-signature:dmarc-filter:delivered-to; bh=4pQlxHlOo4jdZOslQU1JdphGo2fcfrfL3NxDtm5r2Bo=; b=GabhxPk2ZkDiob5KU6JdDqUULEsoy/bzmW0gjiy/ENp+XiMFjgne+Zc6EX+RN+pqaH NWONyWAJFUYKtVk7KczxmZJR2dEPrVKRI0AzOQSvgnpoJEI6CG1iTNUmKTWKxTCqoDkD gB/rVFPwiZVUl3embG4uDFrvGmwtV4TzNR8cclKdX/WhLVwcSRlx86ryVWNyjEEwJQmM 28fbIgmYtw29zhGHGeZ1M0cwh4wKG6IGh4Uw4Aujy9ukeUA/CCHd4vWixkI0/doxyQIF 6wlakU3vDIgPH9RdwZ9D1ngayH3aqKPpMKsrr3WylPBf8d/TUfP7awathUNptxrwQ9+1 xr8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=YeCNuNsJ; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id lb22-20020a170907785600b00730f3cb968fsi2483360ejc.990.2022.09.30.16.33.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 16:33:16 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=YeCNuNsJ; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6A529385415F for ; Fri, 30 Sep 2022 23:33:03 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 26ECD3858D1E for ; Fri, 30 Sep 2022 23:32:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26ECD3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pl1-x630.google.com with SMTP id w24so74945pll.11 for ; Fri, 30 Sep 2022 16:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date; bh=4pQlxHlOo4jdZOslQU1JdphGo2fcfrfL3NxDtm5r2Bo=; b=YeCNuNsJJKh/X+xkSDqQfElJaLIr24pGYomCdbGpfWGvGZnW7k7Ydrht54kY9hochc wBxR3mmmVFVrNmJs7eXAap3EQEjxzD8NWNkqDf8tv5dsM3++YR5Ia0j2imAkRDzl1OCw adjCisiGUQW4vMNhcFnt/1pIXN9fOVIXREsWh13ZSamXfgQomPnsrHZndu9vVlUppq9S xmOWNj1b+6YWKhW5s3+B31r35QKar1MdGyYLnf2laEK6rpYQllU67rcGafxvymq+H2mH U9JpD9HpCuHXqCF8gHZEwiBG5tRkFOe6tGPSEFT010FpYFMUsUTxN164Id4soKBJea1F IgfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=4pQlxHlOo4jdZOslQU1JdphGo2fcfrfL3NxDtm5r2Bo=; b=1pR0O+0lmQoKGpKnKXYGyePIiul3OZ1Nqnjg4+23BLSJoYDoFSYSl3SBdjW9VhWhdk U2MFgusXVoAkLbUhoYb5FXLf653pk6l6mxoPKTFKD+RHfVEhczwp9mqVnIH+vbrK33Oj /G5cdgBCPSHYhRMsOm5RgtDdyBB+x70BVwIJDbbkWYI5RVjROCJMTeNn6kJWjwM0cMMb juAfP0EzfL1PHVPSurhgOOdYWuchsS7UP176g0mOCnTSOQLeAOs6WLNX3IsDkjm1X8p9 7THwkhfPGDwLmwzu0brQkAKSKKo9o6EQ70MWztTp3vAjXzcQGnkwNSBrpnbfDHQQdRwg 7K7w== X-Gm-Message-State: ACrzQf1VpSatdpeP0HHNCKhrIX6OMZkZ/dtBNssLvNRsdBKoZWhCh3ti 0+/AmoLBHegk5t0/59i5im4pyBNjdCSngQDC X-Received: by 2002:a17:90b:1b52:b0:202:f03b:62fd with SMTP id nv18-20020a17090b1b5200b00202f03b62fdmr683366pjb.117.1664580755549; Fri, 30 Sep 2022 16:32:35 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id b11-20020a170902d50b00b0016edd557412sm636363plg.201.2022.09.30.16.32.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 16:32:35 -0700 (PDT) Message-ID: <6baf42b9-0534-dc81-7a54-11317c732a68@ventanamicro.com> Date: Fri, 30 Sep 2022 17:32:34 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Content-Language: en-US To: "gcc-patches@gcc.gnu.org" From: Jeff Law Subject: [committed] More gimple const/copy propagation opportunities X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1745439472662841118?= X-GMAIL-MSGID: =?utf-8?q?1745439472662841118?= While investigating a benchmark for optimization opportunities I came across single block loop which either iterates precisely once or forever.    This is an interesting scenario as we can ignore the infinite looping path and treat any PHI nodes as degenerates. So more concretely let's consider this trivial testcase: volatile void abort (void); void foo(int a) {  int b = 0;  while (1)    {      if (!a)        break;      b = 1;    }  if (b != 0)    abort (); } Quick analysis shows that b's initial value is 0 and its value only changes if we enter an infinite loop.  So if we get to the test b != 0, the only possible value b could have would be 0 and the test and its true arm can be eliminated. The DOM3 dump looks something like this: ;;   basic block 2, loop depth 0, count 118111600 (estimated locally), maybe hot ;;    prev block 0, next block 3, flags: (NEW, VISITED) ;;    pred:       ENTRY [always]  count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;;    succ:       3 [always]  count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;;   basic block 3, loop depth 1, count 1073741824 (estimated locally), maybe hot ;;    prev block 2, next block 4, flags: (NEW, VISITED) ;;    pred:       2 [always]  count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;;                3 [89.0% (guessed)]  count:955630224 (estimated locally) (FALSE_VALUE,EXECUTABLE)   # b_1 = PHI <0(2), 1(3)>   if (a_3(D) == 0)     goto ; [11.00%]   else     goto ; [89.00%] ;;    succ:       4 [11.0% (guessed)]  count:118111600 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;                3 [89.0% (guessed)]  count:955630224 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;;   basic block 4, loop depth 0, count 118111600 (estimated locally), maybe hot ;;    prev block 3, next block 5, flags: (NEW, VISITED) ;;    pred:       3 [11.0% (guessed)]  count:118111600 (estimated locally) (TRUE_VALUE,EXECUTABLE)   if (b_1 != 0)     goto ; [0.00%]   else     goto ; [100.00%] ;;    succ:       5 [never]  count:0 (precise) (TRUE_VALUE,EXECUTABLE) ;;                6 [always]  count:118111600 (estimated locally) (FALSE_VALUE,EXECUTABLE) This is a good representative of what the benchmark code looks like. The primary effect we want to capture is to realize that the test if (b_1 != 0) is always false and optimize it accordingly. In the benchmark, this opportunity is well hidden until after the loop optimizers have completed, so the first chance to capture this case is in DOM3.  Furthermore, DOM wants loops normalized with latch blocks/edges.  So instead of bb3 looping back to itself, there's an intermediate empty block during DOM. I originally thought this was likely to only affect the benchmark.  But when I instrumented the optimization and bootstrapped GCC, much to my surprise there were several hundred similar cases identified in GCC itself.  So it's not as benchmark specific as I'd initially feared. Anyway, detecting this in DOM is pretty simple.   We detect the infinite loop, including the latch block.  Once we've done that, we walk the PHI nodes and attach equivalences to the appropriate outgoing edge.   That's all we need to do as the rest of DOM is already prepared to handle equivalences on edges. Pushed to the trunk, Jeff commit 1214196da79aabbe5c14ed36e5a28012e141f04c Author: Jeff Law Date: Fri Sep 30 19:26:31 2022 -0400 More gimple const/copy propagation opportunities While investigating a benchmark for optimization opportunities I came across single block loop which either iterates precisely once or forever. This is an interesting scenario as we can ignore the infinite looping path and treat any PHI nodes as degenerates. So more concretely let's consider this trivial testcase: volatile void abort (void); void foo(int a) { int b = 0; while (1) { if (!a) break; b = 1; } if (b != 0) abort (); } Quick analysis shows that b's initial value is 0 and its value only changes if we enter an infinite loop. So if we get to the test b != 0, the only possible value b could have would be 0 and the test and its true arm can be eliminated. The DOM3 dump looks something like this: ;; basic block 2, loop depth 0, count 118111600 (estimated locally), maybe hot ;; prev block 0, next block 3, flags: (NEW, VISITED) ;; pred: ENTRY [always] count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;; succ: 3 [always] count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;; basic block 3, loop depth 1, count 1073741824 (estimated locally), maybe hot ;; prev block 2, next block 4, flags: (NEW, VISITED) ;; pred: 2 [always] count:118111600 (estimated locally) (FALLTHRU,EXECUTABLE) ;; 3 [89.0% (guessed)] count:955630224 (estimated locally) (FALSE_VALUE,EXECUTABLE) # b_1 = PHI <0(2), 1(3)> if (a_3(D) == 0) goto ; [11.00%] else goto ; [89.00%] ;; succ: 4 [11.0% (guessed)] count:118111600 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;; 3 [89.0% (guessed)] count:955630224 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 4, loop depth 0, count 118111600 (estimated locally), maybe hot ;; prev block 3, next block 5, flags: (NEW, VISITED) ;; pred: 3 [11.0% (guessed)] count:118111600 (estimated locally) (TRUE_VALUE,EXECUTABLE) if (b_1 != 0) goto ; [0.00%] else goto ; [100.00%] ;; succ: 5 [never] count:0 (precise) (TRUE_VALUE,EXECUTABLE) ;; 6 [always] count:118111600 (estimated locally) (FALSE_VALUE,EXECUTABLE) This is a good representative of what the benchmark code looks like. The primary effect we want to capture is to realize that the test if (b_1 != 0) is always false and optimize it accordingly. In the benchmark, this opportunity is well hidden until after the loop optimizers have completed, so the first chance to capture this case is in DOM3. Furthermore, DOM wants loops normalized with latch blocks/edges. So instead of bb3 looping back to itself, there's an intermediate empty block during DOM. I originally thought this was likely to only affect the benchmark. But when I instrumented the optimization and bootstrapped GCC, much to my surprise there were several hundred similar cases identified in GCC itself. So it's not as benchmark specific as I'd initially feared. Anyway, detecting this in DOM is pretty simple. We detect the infinite loop, including the latch block. Once we've done that, we walk the PHI nodes and attach equivalences to the appropriate outgoing edge. That's all we need to do as the rest of DOM is already prepared to handle equivalences on edges. gcc/ * tree-ssa-dom.cc (single_block_loop_p): New function. (record_edge_info): Also record equivalences for the outgoing edge of a single block loop where the condition is an invariant. gcc/testsuite/ * gcc.dg/infinite-loop.c: New test. diff --git a/gcc/testsuite/gcc.dg/infinite-loop.c b/gcc/testsuite/gcc.dg/infinite-loop.c new file mode 100644 index 00000000000..25037a2027e --- /dev/null +++ b/gcc/testsuite/gcc.dg/infinite-loop.c @@ -0,0 +1,26 @@ +/* { dg-do link } */ +/* { dg-options "-O2" } */ +void link_error (void); + +void __attribute__ ((noinline,noipa)) +foo(int a) +{ + int b = 0; + + while (1) + { + if (!a) + break; + b = 1; + } + + if (b != 0) + link_error (); +} + +int +main() +{ + foo (0); +} + diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc index fa43dbe6c44..8d8312ca350 100644 --- a/gcc/tree-ssa-dom.cc +++ b/gcc/tree-ssa-dom.cc @@ -426,6 +426,74 @@ free_all_edge_infos (void) } } +/* Return TRUE if BB has precisely two preds, one of which + is a backedge from a forwarder block where the forwarder + block is a direct successor of BB. Being a forwarder + block, it has no side effects other than transfer of + control. Otherwise return FALSE. */ + +static bool +single_block_loop_p (basic_block bb) +{ + /* Two preds. */ + if (EDGE_COUNT (bb->preds) != 2) + return false; + + /* One and only one of the edges must be marked with + EDGE_DFS_BACK. */ + basic_block pred = NULL; + unsigned int count = 0; + if (EDGE_PRED (bb, 0)->flags & EDGE_DFS_BACK) + { + pred = EDGE_PRED (bb, 0)->src; + count++; + } + if (EDGE_PRED (bb, 1)->flags & EDGE_DFS_BACK) + { + pred = EDGE_PRED (bb, 1)->src; + count++; + } + + if (count != 1) + return false; + + /* Now examine PRED. It should have a single predecessor which + is BB and a single successor that is also BB. */ + if (EDGE_COUNT (pred->preds) != 1 + || EDGE_COUNT (pred->succs) != 1 + || EDGE_PRED (pred, 0)->src != bb + || EDGE_SUCC (pred, 0)->dest != bb) + return false; + + /* This looks good from a CFG standpoint. Now look at the guts + of PRED. Basically we want to verify there are no PHI nodes + and no real statements. */ + if (! gimple_seq_empty_p (phi_nodes (pred))) + return false; + + gimple_stmt_iterator gsi; + for (gsi = gsi_last_bb (pred); !gsi_end_p (gsi); gsi_prev (&gsi)) + { + gimple *stmt = gsi_stmt (gsi); + + switch (gimple_code (stmt)) + { + case GIMPLE_LABEL: + if (DECL_NONLOCAL (gimple_label_label (as_a (stmt)))) + return false; + break; + + case GIMPLE_DEBUG: + break; + + default: + return false; + } + } + + return true; +} + /* We have finished optimizing BB, record any information implied by taking a specific outgoing edge from BB. */ @@ -435,6 +503,13 @@ record_edge_info (basic_block bb) gimple_stmt_iterator gsi = gsi_last_bb (bb); class edge_info *edge_info; + /* Free all the outgoing edge info data associated with + BB's outgoing edges. */ + edge e; + edge_iterator ei; + FOR_EACH_EDGE (e, ei, bb->succs) + free_dom_edge_info (e); + if (! gsi_end_p (gsi)) { gimple *stmt = gsi_stmt (gsi); @@ -450,8 +525,6 @@ record_edge_info (basic_block bb) int i; int n_labels = gimple_switch_num_labels (switch_stmt); tree *info = XCNEWVEC (tree, last_basic_block_for_fn (cfun)); - edge e; - edge_iterator ei; for (i = 0; i < n_labels; i++) { @@ -583,6 +656,62 @@ record_edge_info (basic_block bb) if (can_infer_simple_equiv && TREE_CODE (inverted) == EQ_EXPR) edge_info->record_simple_equiv (op0, op1); } + + /* If this block is a single block loop, then we may be able to + record some equivalences on the loop's exit edge. */ + if (single_block_loop_p (bb)) + { + /* We know it's a single block loop. Now look at the loop + exit condition. What we're looking for is whether or not + the exit condition is loop invariant which we can detect + by checking if all the SSA_NAMEs referenced are defined + outside the loop. */ + if ((TREE_CODE (op0) != SSA_NAME + || gimple_bb (SSA_NAME_DEF_STMT (op0)) != bb) + && (TREE_CODE (op1) != SSA_NAME + || gimple_bb (SSA_NAME_DEF_STMT (op1)) != bb)) + { + /* At this point we know the exit condition is loop + invariant. The only way to get out of the loop is + if never traverses the backedge to begin with. This + implies that any PHI nodes create equivalances we can + attach to the loop exit edge. */ + int alternative + = (EDGE_PRED (bb, 0)->flags & EDGE_DFS_BACK) ? 1 : 0; + + gphi_iterator gsi; + for (gsi = gsi_start_phis (bb); + !gsi_end_p (gsi); + gsi_next (&gsi)) + { + /* If the other alternative is the same as the result, + then this is a degenerate and can be ignored. */ + if (dst == PHI_ARG_DEF (phi, !alternative)) + continue; + + /* Now get the EDGE_INFO class so we can append + it to our list. We want the successor edge + where the destination is not the source of + an incoming edge. */ + gphi *phi = gsi.phi (); + tree src = PHI_ARG_DEF (phi, alternative); + tree dst = PHI_RESULT (phi); + + if (EDGE_SUCC (bb, 0)->dest + != EDGE_PRED (bb, !alternative)->src) + edge_info = (class edge_info *)EDGE_SUCC (bb, 0)->aux; + else + edge_info = (class edge_info *)EDGE_SUCC (bb, 1)->aux; + + /* Note that since this processing is done independently + of other edge equivalency processing, we may not + have an EDGE_INFO structure set up yet. */ + if (edge_info == NULL) + edge_info = new class edge_info (false_edge); + edge_info->record_simple_equiv (dst, src); + } + } + } } } }