On Wed, Oct 20, 2021 at 1:00 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 10/18/2021 8:03 AM, Aldy Hernandez 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. > The only post-VRP threading pass that (in my mind) makes sense is the > one sitting between VRP and DOM and it should replace the DOM based > threader.
Yes, that's the goal, but it won't happen on this release because of floats. The DOM threader uses the const/avails machinery to thread conditionals involving floats, something the path solver can't do because it depends on gori/ranger. Adding floats to ranger is probably our #1 task for the next cycle. Now before Andrew gets clever, the relation oracle is technically type agnostic, so it could theoretically be possible to use it in the DOM threader and replace all the const/avails stuff. But I'd like to go on vacation at some point ;-). Aldy
