From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 DF7643857818 for ; Tue, 22 Feb 2022 19:18:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF7643857818 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-318-9Wf8POGVPIaSMkVHI0aaNw-1; Tue, 22 Feb 2022 14:18:35 -0500 X-MC-Unique: 9Wf8POGVPIaSMkVHI0aaNw-1 Received: by mail-qv1-f72.google.com with SMTP id a12-20020a056214062c00b0042c2f3fca04so693864qvx.21 for ; Tue, 22 Feb 2022 11:18:35 -0800 (PST) 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:cc:references:from:in-reply-to :content-transfer-encoding; bh=2RL3MDq3x+OVpTTO1KMPNL/PRsi0xz8R0A6f2GcACg8=; b=Ann1TpoFBW08CXvO+wUyhoshTEkjYMaXwPGtZD1YOVkOK9M+g6bTDb2gDQHTiq16A2 xR3K9IjpBeVyujIWDThzP3wGL87Ku0HEsgrvzKKQuBisVu9qvqaPc6Cw7NBX7QvkIEAI bPpplxSPj4SHNqbWfb5wz8PK7ZWg4EWwsmID7JjOpgwxMA8xCRIaZHxH62mG5i0OoL41 MC9K03MWNIzzhJetcgerI1pLKDgr2BTJzVjiFYg+6zsbUtBhUjNrHQvoGKk2xcbc6oP+ NbkxxEqhHOXfYjyd1vJ+oVqX/H26ywDcMKQ36neyxqF66Yh9X3Cg4o/o4AHUNczFbAiC 29lw== X-Gm-Message-State: AOAM530pAk6a60tAPZOTZ4+pMPhaUk8TC+20lr9WOXDNbbHJLEcJuVjF jjsFJEjHrfJw54lrnii+KI0/up4Pi085u/aZxHzhsk9HWrxXwGiZm7uNd51X0L6bz/DSeQTzAjT HoOK+Q7Y/53zssip+qA== X-Received: by 2002:a05:622a:11d3:b0:2de:61df:5d8c with SMTP id n19-20020a05622a11d300b002de61df5d8cmr2887705qtk.597.1645557514585; Tue, 22 Feb 2022 11:18:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJweP1qa7Osf1eyRlHLLadAjpVPrzJxOjIaW7qoYM0vrcKJys18jK7UjdOscW91teRoEMKp0Xg== X-Received: by 2002:a05:622a:11d3:b0:2de:61df:5d8c with SMTP id n19-20020a05622a11d300b002de61df5d8cmr2887675qtk.597.1645557514122; Tue, 22 Feb 2022 11:18:34 -0800 (PST) Received: from ?IPV6:2607:fea8:a262:5f00::9b6f? ([2607:fea8:a262:5f00::9b6f]) by smtp.gmail.com with ESMTPSA id h20sm302208qtk.21.2022.02.22.11.18.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Feb 2022 11:18:33 -0800 (PST) Message-ID: Date: Tue, 22 Feb 2022 14:18:32 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH 0/2] tree-optimization/104530 - proposed re-evaluation. To: Jeff Law , Jakub Jelinek Cc: gcc-patches References: <9328c989-f5c0-084b-4f66-d705d023d474@redhat.com> <72f0c65a-810d-af5b-90e2-1a7d3625a284@gmail.com> From: Andrew MacLeod In-Reply-To: <72f0c65a-810d-af5b-90e2-1a7d3625a284@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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, 22 Feb 2022 19:18:38 -0000 On 2/22/22 13:07, Jeff Law wrote: > > > On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote: >> On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote: >>>> That is EH, then there are calls that might not return because they >>>> leave >>>> in some other way (e.g. longjmp), or might loop forever, might >>>> exit, might >>>> abort, trap etc. >>> Generally speaking, calls which do not return should not now be a >>> problem... >>> as long as they do not transfer control to somewhere else in the >>> current >>> function. >> I thought all of those cases are very relevant to PR104530. >> If we have: >>    _1 = ptr_2(D) == 0; >>    // unrelated code in the same bb >>    _3 = *ptr_2(D); >> then in light of PR104288, we can optimize ptr_2(D) == 0 into true >> only if >> there are no calls inside of "// unrelated code in the same bb" >> or if all calls in "// unrelated code in the same bb" are guaranteed to >> return exactly once.  Because, if there is a call in there which could >> exit (that is the PR104288 testcase), or abort, or trap, or loop >> forever, >> or throw externally, or longjmp or in any other non-UB way >> cause the _1 = ptr_2(D) == 0; stmt to be invoked at runtime but >> _3 = *ptr_2(D) not being invoked, then we can't optimize the earlier >> comparison because ptr_2(D) could be NULL in a valid program. >> While if there are no calls (and no problematic inline asms) and no >> trapping >> insns in between, we can and PR104530 is asking that we continue to >> optimize >> that. > Right.  This is similar to some of the restrictions we deal with in > the path isolation pass.  Essentially we have a path, when traversed, > would result in a *0.  We would like to be able to find the edge > upon-which the *0 is control dependent and optimize the test so that > it always went to the valid path rather than the *0 path. > > The problem is there may be observable side effects on the *0 path > between the test and the actual *0 -- including calls to nonreturning > functions, setjmp/longjmp, things that could trap, etc.  This case is > similar.  We can't back-propagate the non-null status through any > statements with observable side effects. > > Jeff > We can't back propagate, but we can alter our forward view.  Any ssa-name defined before the observable side effect can be recalculated using the updated values, and all uses of those names after the side-effect would then appear to be "up-to-date" This does not actually change anything before the side-effect statement, but the lazy re-evalaution ranger employs makes it appear as if we do a new computation when _1 is used afterwards. ie:    _1 = ptr_2(D) == 0;    // unrelated code in the same bb    _3 = *ptr_2(D);    _4 = ptr_2(D) == 0;      // ptr_2 is known to be [+1, +INF] now. And we use _4 everywhere _1 was used.   This is the effect. so we do not actually change anything in the unrelated code, just observable effects afterwards.  We already do these recalculations on outgoing edges in other blocks, just not within the definition block because non-null wasn't visible within the def block. Additionally, In the testcase, there is a store to C before the side effects. these patches get rid of the branch and thus the call in the testcase as requested, but we still have to compute _3 in order to store it into global C since it occurs  pre side-effect.     b.0_1 = b;     _2 = b.0_1 == 0B;     _3 = (int) _2;     c = _3;     _5 = *b.0_1; No matter how you look at it, you are going to need to process a block twice in order to handle any code pre-side-effect.  Whether it be assigning stmt uids, or what have you. VRP could pre-process the block, and if it gets to the end of the block, and it had at least one statement with a side effect and no calls which may not return you could process the block with all the side effects already active.   I'm not sure if that buys as much as the cost, but it would change the value written to C to be 1, and it would change the global values exported for _2 and _3. Another option would be flag the ssa-names instead of/as well as marking them as stale.  If we get to the end of the block and there were no non-returning functions or EH edges, then re-calculate and export those ssa_names using the latest values..   That would export [0,0] for _2 and _3. This would have no tangible impact during the first VRP pass, but the *next* VRP pass, (or any other ranger pass) would pick up the new global ranges, and do all the right things...  so we basically let a subsequent pass pick up the info and do the dirty work. Andrew