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. > > > > 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. Richard. > Aldy >
