From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 7C6403858D39 for ; Tue, 19 Oct 2021 22:58:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C6403858D39 Received: by mail-pj1-x102d.google.com with SMTP id om14so1067032pjb.5 for ; Tue, 19 Oct 2021 15:58:28 -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=kynwZaMul+WBDJXcIGp91f4bkinJhLYi7eW0BzmoWFA=; b=nLrsKjd+ewe0atBK3WNoygIjCVo4RVErcviTxLcJ/A1CpjuGs5fLxzRA7835kqMARD nrLlGk8WpPtF0QwvW9AFm2KhOcdsdXWJduprOHU6Z1b7bPvJ3wmPccOUEBh4M/uqqDVk vRKuWR7y3J4Ug3vINXYYgbIzZlxDkkdxZOlijF7zeUBbn+yqWdUBAx6TfP0PshLfL8vs Mh+/gHnhyJRNGJXrGBSbb1Micj21OEO7p005pGnG9r+lWc2LGUnYo8VbK2XDc3kOB0jH dOxCXLFl/12sNn0rFKErNLUjiFdoqONvz+rC1rR/5rEX3A0gdADSau4GvlewGhW9wXmn dYvw== X-Gm-Message-State: AOAM532HHF1+8zZg4YiKe4h+1aE3TOUXHyhPjxHgZLiPcBepy2uTawdZ VoBp+J82xjpC4WtbF/8bynM= X-Google-Smtp-Source: ABdhPJxIemLvfbeQM9t65PVJdP563xQ8FPYva9kSAy7gyagfFHey/ru7wiQeDW0EC2Zh7JnAqQIkjQ== X-Received: by 2002:a17:90a:e552:: with SMTP id ei18mr3099367pjb.239.1634684307412; Tue, 19 Oct 2021 15:58:27 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id e12sm259498pfl.67.2021.10.19.15.58.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 15:58:27 -0700 (PDT) Subject: Re: [RFC] Remove VRP threader passes in exchange for better threading pre-VRP. To: Aldy Hernandez , Richard Biener , GCC patches References: <20211018134117.410106-1-aldyh@redhat.com> From: Jeff Law Message-ID: <7cf8f074-b46c-e0c4-c172-1dbe16827ed5@gmail.com> Date: Tue, 19 Oct 2021 16:58:25 -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: <20211018134117.410106-1-aldyh@redhat.com> 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: Tue, 19 Oct 2021 22:58:35 -0000 On 10/18/2021 7:41 AM, Aldy Hernandez wrote: > > 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!). Whoo whoo! > > The numbers look really good. We get 6874 more jump threading passes > over my boostrap .ii files for a total 3.74% increase. And we get that > while running marginally faster (0.19% faster, so noise). > > The details are: > > *** Mainline (with the loop rotation patch): > ethread:64722 > dom:31246 > thread:73709 > vrp-thread:14357 > total: 184034 > > *** Removing all the VRP threaders. > ethread:64722 > thread-full:76493 > dom:33648 > thread:16045 > total: 190908 > > Notice that not only do we get a lot more threads in thread-full > (resolving mode), but even DOM can get more jump threads. > > This doesn't come without risks though. The main issue is that we would > be removing one engine (forward threader), with another one (backward > threader). But the good news is that (a) we've been using the new > backward threader for a while now (b) even the VRP threader in > mainline is using the backward threader solver. So, all that would > really be changing would be the path discovery bits and custom copier > in the forward threader, with the backward threader bit and the > generic copier. > > I personally don't think this is a big risk, because we've done all > the hard work already and it's all being stressed in one way or another. I don't see the risk as significantly different than any other big chunk of development work.  Furthermore, this is a major step on the path we've been discussing the last couple years.   There'll be some testing fallout, but I think that's manageable and ultimately worth the pain to work through.   I can express how happy I am that we're at the point of zapping the two VRP threading passes. > > The untested patch below is all that would need to happen, albeit with > copius changes to tests. > > I'd like to see where we all stand on this before I start chugging away > at testing and other time consuming tasks. > > Note, that all the relevant bits will still be tested in this release, > so I'm not gonna cry one way or another. But it'd be nice to start > reducing passes, especially if we get a 3.74% increase in jump threads > for no time penalty. > > Finally, even if we all agree, I think we should give us a week after the > loop rotation restrictions go in, because threading changes always cause > a party of unexpected things to happen. Sure.  And FWIW, the loop rotation changes are fine IMHO.   So commit those when you're ready, then drop this in a week later.  All in time for stage1 close :-) Jeff