replacing the backwards threader and more

Aldy Hernandez aldyh@redhat.com
Tue Jun 15 05:39:41 GMT 2021



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]??

Aldy



More information about the Gcc mailing list