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 E2FE83858D28 for ; Thu, 18 Aug 2022 13:18:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2FE83858D28 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.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-596-b36hhqIEM6iCgPM84jBpJg-1; Thu, 18 Aug 2022 09:18:46 -0400 X-MC-Unique: b36hhqIEM6iCgPM84jBpJg-1 Received: by mail-qv1-f72.google.com with SMTP id ll16-20020a056214599000b00496a69ff248so938472qvb.8 for ; Thu, 18 Aug 2022 06:18:46 -0700 (PDT) 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; bh=rmyR2CHqQR8bwFxXmcjHy6J3Os1MoAIc6inSlAbKCtM=; b=ktz80htNWhmn8S7oEynwZGPDgwLHKNmhNCsHQhqbbztNONN/dN/1HbiqDavM/ETQnE z8tVnZCaVwMIwfO5NGJfzI2GPYdjwz/EiKa4ZAaV1V3Es2nCfyq3QzAtidP/p+5/Ba4l ESjx9VUO1LhLPCxj/jCsmDThB2CfrY3Aeeuma1f7A42ShmPZ2//iwVI8lKSvFgwFM6/q IbVEw5pWtAVRjIXYv5cWWguzyqy1cnzqKTGVK/SaJXlg185+IYr6oyyrWziC5kS8En5x 09px632rvcg8v5MMjyWRdVwnFF41AjULg9/UeyLTWSsGO38eU+Ttfrwf+lXQug6fZDO3 MC9Q== X-Gm-Message-State: ACgBeo2SIwr/dNLKgA2Lkbn/JNz3+W43QOECBOPj7wfTZhYIHFjpmIU6 q+5i2yDBYQCJJHMByHaoymPLV1pLJWCOkmgpadCM7OxPhhuD1kC33D/fo3B7jHVK1+YqnfhsBOW Ng5KsjW5lS/GhmbOrDQ== X-Received: by 2002:a05:620a:1990:b0:6bb:61c3:8970 with SMTP id bm16-20020a05620a199000b006bb61c38970mr2009501qkb.394.1660828725745; Thu, 18 Aug 2022 06:18:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR6Jcr8Wq6WiRgmnmS88bZ9U+fl95tXTyZT6Q1RzKc0nsUhweCCbLGBh8cEI9nIU/E/gsb4Qcw== X-Received: by 2002:a05:620a:1990:b0:6bb:61c3:8970 with SMTP id bm16-20020a05620a199000b006bb61c38970mr2009482qkb.394.1660828725480; Thu, 18 Aug 2022 06:18:45 -0700 (PDT) Received: from [192.168.0.135] ([192.24.49.145]) by smtp.gmail.com with ESMTPSA id j10-20020ac8664a000000b0033fc75c3469sm957013qtp.27.2022.08.18.06.18.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Aug 2022 06:18:44 -0700 (PDT) Message-ID: <09ab3062-835d-4cf1-c432-98e084fea30c@redhat.com> Date: Thu, 18 Aug 2022 09:18:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Support threading of just the exit edge To: Richard Biener Cc: Aldy Hernandez , Jeff Law , gcc-patches References: <20220812120145.91C6513AAE@imap2.suse-dmz.suse.de> <3b6265b1-a0ab-f0b7-2d1f-aaf6277eec14@redhat.com> <4c846dc9-0044-35d2-dd9a-87ec93dd8d75@redhat.com> <7dbd0ee3-638a-1b84-9be9-9310eefdce11@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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-List-Received-Date: Thu, 18 Aug 2022 13:18:49 -0000 On 8/18/22 03:08, Richard Biener wrote: > >> The caveat is that it is only a partial solution... it will only work for >> names on that stmt.  if you have anything more complex, ie >> >> if (a == 0 || b == 0)  we have a seqeunce feeding the ctrl stmt.. >> >> c_1 = a == 0 >> c_2 = b == 0 >> c_3 = c_1 && c_2 >> if (c_3 == 0) >> >> only the evaluation of c_3 will have the ctrl stmt as its context.. the others >> will be evaluted on their own statement, and thus neither a nor b would pick >> up anything from the block as they are evalauted and cached as they are >> seen.    unless of course we are doing a walk :-P > Hmm, but as I traced it when I do range_of_expr the context stmt I provide > will be passed down and even when processing dependences that context > will stick? But maybe it doesn't because it would mean explosion of the > cache? > > But yeah, with the above restriction it would be even more useless. > Same issue as with > > *p = 0; > if (..) > / \ > .. \ > if (p) > > here the local adjustment of 'p' in if (p) would not pick up the > p != 0 guarantee from the immediate dominator. it certainly should. the earlier BB will have the ~[0, 0] property in the on-exit structure, so when the range of 'p' is evaluated on the edge to the next block, it will be adjusted. the value for on-entry of P to that block will therefore be ~[0, 0].   Ranger does this, and the path query code is *suppose* to.. late discussions with Aldy yesterday left me unclear if it always does.  it should.  that was the entire point of leaving the on-demand filling of the structure via immediate uses. >>  In the meantime, >> it should be possible to take a ranger that just completed a VRP pass, and use >> that as the root ranger for a threading pass immediately after.. I think there >> may be some lingering issues with abnormal edges if we "re-visit" blocks which >> we claim to have walked due to the way I store inferred ranges in those >> block.. (the expectation being we never go back up into the block, so the >> on-entry cache works like the "current def" vector in the original EVRP.  I'd >> have to think about that too. > Of course that would essentially do a VRP pass before each threading > which I think is a bit expensive. Also looking at how ranger works > with all its abstraction having the "old" EVRP style body walk rather > than abusing the on-demand ranger for such a walk would be a lot more > efficient for this purpose :/ No, I just meant when we do the VRP pass, rather than throw away the fully primed ranger and its values, one could invoke the threader using it...  But I'm not sure how much extra we'd get anyway. >>> Meanwhile I'm leaning towards calling this a phase ordering issue >>> of threading + VRP, but that also means we shouldn't deliberately >>> try to preserve "threadings" of this kind - in fact we might want >>> to explicitely reject them? >> we are probably going to want to visit some pass ordering. > Sure, though there's never going to be a good enough pass ordering :/ > > Richard.