From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by sourceware.org (Postfix) with ESMTPS id 5C15C3858C54 for ; Sun, 26 Jun 2022 18:23:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C15C3858C54 Received: by mail-io1-xd29.google.com with SMTP id s17so7565501iob.7 for ; Sun, 26 Jun 2022 11:23:54 -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:references:from:in-reply-to :content-transfer-encoding; bh=a7rf/yUyHjFxZ1pV+LJEtV6l67+T8jkGC/RTVlyNXMY=; b=Bi9yXIlzx62fHOcpqO8qiZtiFuFAhcvqLFhj/r7ITYH/J10Pl/rilDuViEorDSV+V0 aenxlUY/mR0rpUvDixR0UZa+RoM+F01fHUZzflokg+sSa93P+ihG5gRh/cNzUqICHb3/ TD8KomaJgNIMiPia7KCCLXReayTlZRueOgrlt86oiaeAHuFAAQViFKQhuzDKedkv/sUd SkZ1skarcyR90M5/AYyBkQM3dHpU09WngiW9k2DwFQNWn8HEfrZ5EP27UwjwcoCDmJQZ yYiir0hmFX3FO+iRaydLn4Q/Rb98TLdkEc6gDpILgdDd/jQkf1E5VzQTANam1K0dctnX qKxQ== X-Gm-Message-State: AJIora/juS/IoQiOWf/EpVOJcJVb6KLp2CzE4rOcvGl+ZQre/PuRd2xQ 0lojGDPuA6M50p5boMxC52ZFJWg4MUI= X-Google-Smtp-Source: AGRyM1tiLl7aVqlZNe8jaK0UkLikXJGP2fNEjBoKHFCIukSbO5Y3Mz/xF7clNEk7MbPyX51+mUYh8g== X-Received: by 2002:a6b:3115:0:b0:660:d5f1:e3b6 with SMTP id j21-20020a6b3115000000b00660d5f1e3b6mr4685834ioa.99.1656267833000; Sun, 26 Jun 2022 11:23:53 -0700 (PDT) Received: from [192.168.43.42] ([172.58.38.202]) by smtp.gmail.com with ESMTPSA id z22-20020a5e8616000000b00674f8979801sm4292688ioj.0.2022.06.26.11.23.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jun 2022 11:23:52 -0700 (PDT) Message-ID: Date: Sun, 26 Jun 2022 12:23:50 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 2/2] tree-optimization/104530 - Mark defs dependent on non-null stale. Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <16cb11c5-c46e-b0ae-2813-52f141414a41@redhat.com> From: Jeff Law In-Reply-To: <16cb11c5-c46e-b0ae-2813-52f141414a41@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, BODY_8BITS, 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, 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-List-Received-Date: Sun, 26 Jun 2022 18:23:55 -0000 On 2/22/2022 9:40 AM, Andrew MacLeod via Gcc-patches wrote: > This patch simply leverages the existing computation machinery to > re-evaluate values dependent on a newly found non-null value > > Ranger associates a monotonically increasing temporal value with every > def as it is defined.  When that value is used, we check if any of the > values used in the definition have been updated, making the current > cached global value stale.  This makes the evaluation lazy, if there > are no more uses, we will never re-evaluate. > > When an ssa-name is marked non-null it does not change the global > value, and thus will not invalidate any global values.  This patch > marks any definitions in the block which are dependent on the non-null > value as stale.  This will cause them to be re-evaluated when they are > next used. > > Imports: b.0_1  d.3_7 > Exports: b.0_1  _2  _3  d.3_7  _8 >          _2 : b.0_1(I) >          _3 : b.0_1(I)  _2 >          _8 : b.0_1(I)  _2  _3  d.3_7(I) > >    b.0_1 = b; >     _2 = b.0_1 == 0B; >     _3 = (int) _2; >     c = _3; >     _5 = *b.0_1;        <<-- from this point b.0_1 is [+1, +INF] >     a = _5; >     d.3_7 = d; >     _8 = _3 % d.3_7; >     if (_8 != 0) > > when _5 is defined, and n.0_1 becomes non-null,  we mark the dependent > names that are exports and defined in this block as stale.  so _2, _3 > and _8. > > When _8 is being calculated, _3 is stale, and causes it to be > recomputed.  it is dependent on _2, alsdo stale, so it is also > recomputed, and we end up with > >   _2 == [0, 0] >   _3 == [0 ,0] > and _8 = [0, 0] > And then we can fold away the condition. > > The side effect is that _2 and _3 are globally changed to be [0, 0], > but this is OK because it is the definition block, so it dominates all > other uses of these names, and they should be [0,0] upon exit anyway.  > The previous patch ensure that the global values written to > SSA_NAME_RANGE_INFO is the correct [0,1] for both _2 and _3. > > The patch would have been even smaller if I already had a mark_stale > method.   I thought there was one, but I guess it never made it in > from lack of need at the time.   The only other tweak was to make the > value stale if the dependent value was the same as the definitions. > > This bootstraps on x86_64-pc-linux-gnu with no regressions. Re-running > to ensure. > > OK for trunk? or defer to stage 1? Seems reasonable now that we're in stage1.  Obviously given the time between original posting and now you should probably bootstrap and regression test it again. Jeff