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