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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 412F63858C3A for ; Wed, 20 Oct 2021 09:28:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 412F63858C3A Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-573-3SSWyHRUOQajdZOSj_1eSA-1; Wed, 20 Oct 2021 05:28:03 -0400 X-MC-Unique: 3SSWyHRUOQajdZOSj_1eSA-1 Received: by mail-lf1-f72.google.com with SMTP id br42-20020a056512402a00b003fd94a74905so2877466lfb.7 for ; Wed, 20 Oct 2021 02:28:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FV7xZ7G3M0T2rIVijL+EsXmDFcWIixBiNZ8omTrcXO8=; b=ge3M5ZyQh4JrUBElM86JWBqDS8cNWir7Pw/ExNIvPLBx4y68lE7fJuPCVRToEsMobH q0VVmQlj7anPeRgVPH0MlYKtfed2pRYLK+ZsxBRIUnjUqsHuNbKZS9Lqo4Q97jUA8/ni 1jLgsperqyHVFxo7OTEDrXZJlKPGETyCSvhB3FBEsvQCcH+I5QN5NzGaMYJMX3S617N7 CtKH1aBEhhLZsN/xEPEGVSl0zqgPegWw6+hv4KbzZXZOdvmNx235AcmRgZdiDOZSoOl1 dvwVefTMyyf31vgxmwk0lGoXAnNO9CnrAlUVzlUIbCdQ9W98VU7Syik8/REN0IpKgljY tK5g== X-Gm-Message-State: AOAM531lQeT+zyiPP3wyye/TL4jOr6ERPOIXIHzQIwwi6IuYbCR2H0bz sNSqFzJu4wa5pFyDsv7ca/7jGe5Gw3p3hlHtIdFxRJAOPErRBE3tTJePN5JZzx7CenK3lsMkFGj WWfH97QYoW9WgBIeS29WeZJ0qhOuwBowMXg== X-Received: by 2002:a2e:7308:: with SMTP id o8mr11875055ljc.360.1634722082153; Wed, 20 Oct 2021 02:28:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydLiUv0A3xGLP5OUhb1dg8ZhiZC5JBDePNJxs0r483y1iSDB1bYkCzRiakHpa0BYkz9d4Klfa4ju1Vp2AceDc= X-Received: by 2002:a2e:7308:: with SMTP id o8mr11875034ljc.360.1634722081895; Wed, 20 Oct 2021 02:28:01 -0700 (PDT) MIME-Version: 1.0 References: <20211018134117.410106-1-aldyh@redhat.com> <69d78e89-c086-d10c-901f-72f504aeb93f@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Wed, 20 Oct 2021 11:27:50 +0200 Message-ID: Subject: Re: [RFC] Remove VRP threader passes in exchange for better threading pre-VRP. To: Jeff Law Cc: Richard Biener , GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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: Wed, 20 Oct 2021 09:28:06 -0000 On Wed, Oct 20, 2021 at 1:00 AM Jeff Law wrote: > > > > On 10/18/2021 8:03 AM, Aldy Hernandez wrote: > > > > > > On 10/18/21 3:41 PM, Aldy Hernandez wrote: > > > >> I've been experimenting with reducing the total number of threading > >> passes, and I'd like to see if there's consensus/stomach for altering > >> the pipeline. Note, that the goal is to remove forward threader > >> clients, > >> not the other way around. So, we should prefer to remove a VRP threader > >> instance over a *.thread one immediately before VRP. > >> > >> After some playing, it looks like if we enable fully-resolving mode in > >> the *.thread passes immediately preceeding VRP, we can remove the VRP > >> threading passes altogether, thus removing 2 threading passes (and > >> forward threading passes at that!). > > > > It occurs to me that we could also remove the threading before VRP > > passes, and enable a fully-resolving backward threader after VRP. I > > haven't played with this scenario, but it should be just as good. > > That being said, I don't know the intricacies of why we had both pre > > and post VRP threading passes, and if one is ideally better than the > > other. > The only post-VRP threading pass that (in my mind) makes sense is the > one sitting between VRP and DOM and it should replace the DOM based > threader. Yes, that's the goal, but it won't happen on this release because of floats. The DOM threader uses the const/avails machinery to thread conditionals involving floats, something the path solver can't do because it depends on gori/ranger. Adding floats to ranger is probably our #1 task for the next cycle. Now before Andrew gets clever, the relation oracle is technically type agnostic, so it could theoretically be possible to use it in the DOM threader and replace all the const/avails stuff. But I'd like to go on vacation at some point ;-). Aldy