From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 34EFA3858015 for ; Mon, 31 Oct 2022 22:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34EFA3858015 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102e.google.com with SMTP id b1-20020a17090a7ac100b00213fde52d49so1767953pjl.3 for ; Mon, 31 Oct 2022 15:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MkRauDc/BVuX9342DQJmC3zKO3sPDpHJCeDG/kdZKbI=; b=YxWshAmdk/UueqBb4JgaBz7uKTQw5u4lbliJdbEDl4LIN0I8i5eLdD40rXTnJB6far HU5KrE21u1tAoStJrdpPCWvBDBU0yn8GXn45mDb58sI6ONCldiqEZ1FLOC7dEUAE4Jg7 Y+cdJQqsXUjPCS47/ta5y1TTy3AXlPy0k06noO5rB0algi6skcMWp2sQKn8FOb3fZ17a 4YxjifQDJBcRz/3k1ZN7RYaevwMa+CEQFc35wYJbxVpd3RvAtvKiryoT2LoneQGDYlPM KCVaOAlVgbTZK6X+Zq3zxbnvFR6XaYYNeD8UkbXO40jwjkC+6QhtuE/QId5bKt8ZSJXU TEgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MkRauDc/BVuX9342DQJmC3zKO3sPDpHJCeDG/kdZKbI=; b=ZdjA6LYKBSub3WlnubdYsJvTvm8HvCiqtuqwI2NtPF5T4BqDeH3QeSGT32GGa/oMEw NeRHN4uxPVVexXcggw01tl8f8nz0IJOR1rVPcSU6/eluJTAckDOEAoOtlBpq0C7waoGZ 8DTOK6Mf84NMlTdThRv3vbX7EnYKLLobfWJUN5aTyX5sxrcgo8bO+BhAcB964UGhx16H d3D9BUkJVrRHC/5OVEKcMBNfVaQJgaBPWsaF2DFgv2876XAFW0/douPs+MaU/zZCJXVW jX2ymfHluhL/TLi8cwrQtFk9DMJ9Ui8uUjsRzRa0F7QbPB946BLE/gaAAz2vq6ptc/qI zbrg== X-Gm-Message-State: ACrzQf17Z9GeHK+Fo/Ce4t/s6/a40xWotttiduf68h9+gGfYsoXypKP1 80FSm3U2TLuK+M3rwDhMh+M= X-Google-Smtp-Source: AMsMyM6M9LrypVubjPeZ7oi8i5VbbXwvvyGW5RAZDlyQmtTG+x5dfJPWpx45Y4DhdJXJHqE9j6Gxlw== X-Received: by 2002:a17:90b:1c8d:b0:203:cc25:4eb5 with SMTP id oo13-20020a17090b1c8d00b00203cc254eb5mr17173101pjb.132.1667256223973; Mon, 31 Oct 2022 15:43:43 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id b5-20020a655785000000b00439d071c110sm4650256pgr.43.2022.10.31.15.43.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 15:43:43 -0700 (PDT) Message-ID: <235a80ee-97dc-2f78-e1b1-eb355ccde4fc@gmail.com> Date: Mon, 31 Oct 2022 16:43:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [committed] More gimple const/copy propagation opportunities Content-Language: en-US To: Bernhard Reutner-Fischer , Jeff Law Cc: "gcc-patches@gcc.gnu.org" References: <6baf42b9-0534-dc81-7a54-11317c732a68@ventanamicro.com> <20221001205534.706b2024@nbbrfq> From: Jeff Law In-Reply-To: <20221001205534.706b2024@nbbrfq> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 List-Id: On 10/1/22 12:55, Bernhard Reutner-Fischer wrote: > On Fri, 30 Sep 2022 17:32:34 -0600 > Jeff Law wrote: > >> + /* 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; > So, given the below, neither DEBUG nor labels do count towards an > empty seq [coming in from any PHI that is, otherwise it's a different > thing], which is a bit surprising but well, ok. It looks at PHI IL, so > probably yes. Allegedly that's what it is. Neat if that's true. Right.  A forwarder block is allowed to have local labels, but not labels for nonlocal gotos, so we can and should ignore local labels.  Debug statements must be ignored or you can end up with differing code generation based on whether or not -g is enabled or not. In some contexts PHIs are allowed in forwarders, in other contexts they are not.  In this specific case I doubt it matters because of the restrictions we put on the CFG, the predecessor block is restricted to a single incoming edge.  The only way that'll have a PHI is if the PHI became a degenerate during DOM. > >> + >> + 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; > don't like, sounds odd. Are we sure there's no other garbage that can > manifest here? int meow=42;, and meow unused won't survive?, pragmas > neither or stuff ? That would generate a real statement and would thus be rejected. If there's anything other than a local label or debug statements in the block, then it's rejected. >> @@ -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 > s/if /if it / Will fix.  THanks. > >> + implies that any PHI nodes create equivalances we can > that any threw me off asking for "that if any". Would have been nicer, > i think? All PHIs at the target of the loop backedge in this case create an equivalence.  That's the whole point of the patch, to prove a set of circumstances that ultimately require all the PHIs on the loop backedge to create an equivalence on the loop exit. > >> + attach to the loop exit edge. */ > attach it to Updated, slightly differently, but should be clearer. > >> + int alternative > bool Sure. > >> + = (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) > by now, alternative would be easier to grok if it would have been spelled > from_backedge_p or something. IMHO. Agreed it's a bit ugly.  Let me think about  how to clean this up. Anyway, I've queued the updates.  I'll push them the next time I do a bootstrap & regression test. jeff