On Tue, Oct 19, 2021 at 11:06 AM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 10/19/21 10:40 AM, Richard Biener wrote: > > On Tue, Oct 19, 2021 at 9:33 AM Aldy Hernandez <al...@redhat.com> wrote: > >> > >> On Tue, Oct 19, 2021 at 8:52 AM Richard Biener > >> <richard.guent...@gmail.com> wrote: > >>> > >>> On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez <al...@redhat.com> wrote: > >>>> > >>>> > >>>> > >>>> On 10/18/21 3:41 PM, Aldy Hernandez wrote: > >>>> > >>>>> I've been experimenting with reducing the total number of threading > >>>>> passes, and I'd like to see if there's consensus/stomach for altering > >>>>> the pipeline. Note, that the goal is to remove forward threader > >>>>> clients, > >>>>> not the other way around. So, we should prefer to remove a VRP threader > >>>>> instance over a *.thread one immediately before VRP. > >>>>> > >>>>> After some playing, it looks like if we enable fully-resolving mode in > >>>>> the *.thread passes immediately preceeding VRP, we can remove the VRP > >>>>> threading passes altogether, thus removing 2 threading passes (and > >>>>> forward threading passes at that!). > >>>> > >>>> It occurs to me that we could also remove the threading before VRP > >>>> passes, and enable a fully-resolving backward threader after VRP. I > >>>> haven't played with this scenario, but it should be just as good. That > >>>> being said, I don't know the intricacies of why we had both pre and post > >>>> VRP threading passes, and if one is ideally better than the other. > >>> > >>> It was done because they were different threaders. Since the new threader > >>> uses built-in VRP it shouldn't really matter whether it's before or after > >>> VRP _for the threading_, but it might be that if threading runs before VRP > >>> then VRP itself can do a better job on cleaning up the IL. > >> > >> Good point. > >> > >> FWIW, earlier this season I played with replacing the VRPs with evrp > >> instances (which fold far more conditionals) and I found that the > >> threaders can actually find LESS opportunities after *vrp fold away > >> things. I don't know if this is a good or a bad thing. > > > > Probably a sign that either threading theads stuff that's pointless > > (does not consider conditions on the path that always evaluate false?) > > At least in the backward threader, we don't keep looking back if we can > resolve the conditional at the end of an in-progress path, so it's > certainly possible we thread paths that are unreachable. I'm pretty > sure that's also possible in the forward threader. > > For example, we if we have a candidate path that ends in x > 1234 and we > know on entry to the path that x is [2000,3000], there's no need to > chase further back to see if the path itself is reachable.
For that matter, when I was working on replacing the DOM threader, I found out that the forward threader + evrp routinely tried to thread paths that were unreachable, and I had to trim them from my comparison tally. The new backward threader engine suffers less from this, because if there is an UNDEFINED range as part of the in-path calculation, we can trim the path as unreachable (and avoid further searches in that direction). However, as I said, if the range is known on entry, we do no further lookups and happily thread away. Aldy
