replacing the backwards threader and more

[Jeff Law]

On 6/14/2021 11:39 PM, Aldy Hernandez wrote:
>
>
> On 6/15/21 6:03 AM, Jeff Law wrote:
>>
>>
>> On 6/14/2021 12:40 AM, Richard Biener wrote:
>>>
>>>> I bet it's going to be tougher to remove DOM's threader.  It knows how
>>>> to do thinks like resolve memory references using temporary 
>>>> equivalences
>>>> and such.  But I bet it's enough to drop the VRP based threaders.
>>> Yes.  In fact I am wondering if adding threading to the not 
>>> iterating FRE
>>> would make it possible to drop DOM, replacing it with instances of FRE.
>> I'd think so.  I'd approach as:
>>
>> 1. Remove the VRP threader instances.
>> 2. Drop cprop and redundancy elimination from DOM using FRE instead
>> 3. What's left of DOM is just forward jump threading.  Revamp & 
>> simplify.  Then either make it a distinct pass or as a sub-pass of FRE.
>>
>> But one could just as easily look at adding threading to FRE and just 
>> killing DOM and its jump threading.
>
> Andrew will hopefully be contributing the relational work this week. 
> Once he does so, I will gather more granular stats for VRP1/VRP2 so we 
> can assess the situation.
>
> Also, a bunch of tests needed to be tweaked because the new code picks 
> up so many threads.  I'm waiting for the relational work to avoid 
> having to adjust the tests again.
>
> I would personally prefer to add an item 0 to the above list: replace 
> current backwards threader code with the rewrite.  I would hate to 
> replace all threaders at once and deal with the fallout. Perhaps it's 
> better to replace the backward threaders, and once that settles move 
> onto VRP[12]??
Sorry, yes, there's a step #0, replace the backwards threader. Mentally 
I groups that with "Remove VRP threader instsances", but it's a distinct 
step and a prerequisite.

jeff