From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id ADB513858C3A for ; Wed, 20 Oct 2021 17:55:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADB513858C3A Received: by mail-pj1-x102f.google.com with SMTP id n36-20020a17090a5aa700b0019fa884ab85so1070744pji.5 for ; Wed, 20 Oct 2021 10:55:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Y4vm5epkL2Te37yZhjQycvNwXC13Db2u3Xe77JfuuqU=; b=hHmxLULSU2b3Iqfr1SCquThHvG5aZFi3klMYZfuGd9XBMBh0KJytE4V0tBGNtfaVfz o44Yg/JROjyQRsjCHt8xxnpIgm8k48hbzJHo5NZqO3ryGwPxWmUkcrenGiyZrIw4SgVs RHwPU525riho7l4IeaBq2LhViZKsmLgCxBRBV2+LfbnIgNqkPsXh1kUzC0H+y6yXCPOW 9NRi8tYRaDMHv863uwPOamP8fxB0vkFL4GBBpDGtjkFfiwe115lS/tLXFJw55z9RIiLc /NH35v0j4VdZZbO2I4X9Gt8pBzlVVdsx1f3n4/h/vAA6LTDe+3sc0cReZ2y4QKEBeMZG KlJg== X-Gm-Message-State: AOAM531utj5a8CyxRGBbpA1QsEHG/zZtwcTMk/nl5beT1fZHsG31jk6v SfvrQesZ8Sn+k8EjaJXMFNc= X-Google-Smtp-Source: ABdhPJzKcOfQLLKh6DTU8x5teEa1eD9gHjKqtZ1kd9mcPlETm9re7I6VTbGKbJmY92XkOjb55AblMA== X-Received: by 2002:a17:903:1c7:b0:13e:d05b:ed09 with SMTP id e7-20020a17090301c700b0013ed05bed09mr505223plh.52.1634752509491; Wed, 20 Oct 2021 10:55:09 -0700 (PDT) Received: from [192.168.1.24] (65-130-88-192.slkc.qwest.net. [65.130.88.192]) by smtp.gmail.com with ESMTPSA id l11sm6476976pjg.22.2021.10.20.10.55.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 10:55:08 -0700 (PDT) Subject: Re: [RFC] Remove VRP threader passes in exchange for better threading pre-VRP. To: Aldy Hernandez Cc: Richard Biener , GCC patches , Andrew MacLeod References: <20211018134117.410106-1-aldyh@redhat.com> <69d78e89-c086-d10c-901f-72f504aeb93f@redhat.com> From: Jeff Law Message-ID: <17f13c59-dda5-a774-2936-3ee881124476@gmail.com> Date: Wed, 20 Oct 2021 11:55:07 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.5 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.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 17:55:12 -0000 On 10/20/2021 3:27 AM, Aldy Hernandez wrote: > 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 ;-). Correct.  I just wanted to make it clear that as the backwards threader improves I see less and less of a need to run as many threader passes. For VRP1 -> DOM2, I could see removing the threading path from DOM2 and having a backwards threader between VRP1 and DOM2.  I don't see significant value in having a threading pass of any sort after VRP2 as the vast majority of things are handled by then. Jeff