Re: [RFC] Remove VRP threader passes in exchange for better threading pre-VRP.

[Aldy Hernandez <aldyh@redhat.com>]

On Tue, Oct 19, 2021 at 11:06 AM Aldy Hernandez <aldyh@redhat.com> wrote:
>
>
>
> On 10/19/21 10:40 AM, Richard Biener wrote:
> > On Tue, Oct 19, 2021 at 9:33 AM Aldy Hernandez <aldyh@redhat.com> wrote:
> >>
> >> On Tue, Oct 19, 2021 at 8:52 AM Richard Biener
> >> <richard.guenther@gmail.com> wrote:
> >>>
> >>> On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez <aldyh@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