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
>

Reply via email to