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.
Oh, I just noticed...we already key off of -fexpensive-optimizations. Duh. The only backward threader that runs at -O1 is ethread, which does not fully resolve. So I think we're good. But your comment still applies when we kill the DOM threader and replace it with a pre-DOM fully resolving threader, since DOM does run at -O1. Ughhh.. I really hate that DOM is an evrp pass in disguise but at -O1. Aldy
