On Fri, Oct 29, 2021 at 10:10 AM Richard Biener <richard.guent...@gmail.com> wrote: > > On Fri, Oct 29, 2021 at 10:06 AM Aldy Hernandez <al...@redhat.com> wrote: > > > > On Fri, Oct 29, 2021 at 9:30 AM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > Btw, in case the "fully resolving" mode is slower than not fully resolving > > > please consider gating it on -fexpensive-optimizations (aka -O2+), thus > > > run the passes in not fully resolving modes at-O1. > > > > Sorry for the awkward naming. I couldn't find a better name :-/. > > Suggestions welcome. > > > > The fast mode assumes any unknown ranges on entry to a path to be > > VARYING, whereas the fully resolving mode will ask the ranger, so the > > fully resolving mode will indeed be slower. Though, I haven't > > measured how much. However, we are gaining some time in total > > compilation speed (1.32%) by replacing two threaders with one. > > OK. Just again, -O1 is to favor compile-speed and should crunch through > those incredibly stupi^Wlarge machine-generated sources without problems. > But from your comment it doesn't sound like something completely unreasonable > or slow.
It shouldn't be a problem. Andrew has worked hard at handling those large CFGs, and I'm just leveraging his work. The backward threader also has a limit of 10 blocks look-back. But if it becomes a problem, I'm more than happy to gate the fully resolving threader with fexpensive-optimizations, but we will lose threading ability at -O1. I assume that's OK? FWIW, Andrew has mentioned providing a fast mode for the ranger for precisely those huge CFGs. Perhaps when that's ready, we could use that mode for -O1. > > > > > > > Btw, there were quite a few big compile-time hogs with the vrp_threader > > > passes, not sure if this solves those. > > > > Sorry for not commenting on your spec ltrans report. I was waiting > > until this went in to get a better feel of whether it was the path > > solver, the forward threader, or something else. When I commit this > > patch we'll get the forward threader out of the set of variables to > > examine. The forward threader, for instance, has very few knobs > > limiting its behavior, and coupled with a smarter solver, who knows > > what's going on. > > > > It is possible we may need to add a few knobs (or re-add some of the > > ones I removed??), since the backward threader can find a whole slew > > of paths that the forward threader could never find. > > Yeah, sure. I'll wait unless this change is in and will re-measure and update > the PR. I'm working through a regression on ppc64, but I should be able to push later today. Thanks. Aldy
