[PATCH] Remove VRP threader passes in exchange for better threading pre-VRP.

[Aldy Hernandez]

On Fri, Oct 29, 2021 at 9:30 AM Richard Biener
<richard.guenther@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.

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

Aldy