PING. Note, that there are no PRs and nothing really dependent on this patch. This has just been suggested as the right thing to do wrt loops.
This patch fixes 6 XFAILs in our testsuite and has the added side-effect of fixing the aarch64 bootstrap problem (though the problem in the uninit code is still there). This is a fundamental change in what we've traditionally allowed for jump threading, but I think it's a good thing. It also paves the way for combining the validity models for both the forward and the backward threaders. I am happy to field the PRs this may bring about, since every change in the cost model has us questioning whether we should or shouldn't thread a path. But I may need some help from y'all if there's a missing thread that causes a regression in some other pass. That being said, most of the issues that have come with the threader changes haven't been because we thread less, but because we thread more-- so perhaps restricting things is a good thing ;-). Aldy On Wed, Oct 6, 2021 at 12:22 PM Aldy Hernandez <al...@redhat.com> wrote: > > [Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests > on aarch64 and ppc64le.] > > There is a lot of fall-out from this patch, as there were many threading > tests that assumed the restrictions introduced by this patch were valid. > Some tests have merely shifted the threading to after loop > optimizations, but others ended up with no threading opportunities at > all. Surprisingly some tests ended up with more total threads. It was > a crapshoot all around. > > On a postive note, there are 6 tests that no longer XFAIL, and one > guality test which now passes. > > I would appreciate someone reviewing the test changes. I am unsure > whether some of the tests should be removed, XFAILed, or some other > thing. > > I felt a bit queasy about such a fundamental change wrt threading, so I > ran it through my callgrind test harness (.ii files from a bootstrap). > There was no change in overall compilation, DOM, or the VRP threaders. > > However, there was a slight increase of 1.63% in the backward threader. > I'm pretty sure we could reduce this if we incorporated the restrictions > into their profitability code. This way we could stop the search when > we ran into one of these restrictions. Not sure it's worth it at this > point. > > Note, that this ad-hoc testing is not meant to replace a more thorough > SPEC, etc test. > > Tested on x86-64 Linux. > > OK pending tests on aarch64 and ppc64le? > > Co-authored-by: Richard Biener <rguent...@suse.de>
