Re: More aggressive threading causing loop-interchange-9.c regression

[Aldy Hernandez <aldyh@redhat.com>]

On 9/10/21 5:51 PM, Jeff Law wrote:
> 
> 
> On 9/9/2021 4:15 AM, Richard Biener wrote:
>>
>>> b) Even though we can seemingly fold everything DOM/threader does, in
>>> order to replace it with a backward threader instance we'd have to merge
>>> the cost/profitability code scattered throughout the forward threader,
>>> as well as the EDGE_FSM* / EDGE_COPY* business.
>>>
>>> c) DOM changes the IL as it goes.  Though we could conceivably divorce
>>> do the threading after DOM is done.
>> Yeah, it does not actually process/simplify the blocks copied by 
>> threading.
>> In fact I think it only registers jump threading opportunities during 
>> the DOM
>> walk and commits them only later.  But it of course uses its avail / 
>> copies
>> stack to find them - that part you cannot easily divorce.
> Well, divorcing from using the context sensitive avail/copies is part of 
> what Aldy & Andrew have been working on.  All indications I've seen are 
> they're on track to be able to do that.
> 
> And yes, it only registers the threads and waits until after DOM is done 
> to transform the CFG.  That in and of itself introduces all kinds of 
> complexity.  If we can get to the point where we don't need the context 
> sensitive avail/copies, then we've got a real shot at untangling DOM and 
> threading which would be a huge maintainability win in my mind.
> 
>>
>> DOM is also yet another value-numbering framework - one could think
>> of stripping it down from that side, keeping the threading bits only
>> (but you'd still have the avail / copies bits).
> Yes.  I think you and I touched on this a while back.    At a high level 
> I'd prefer to have FRE rather than DOM doing the bulk of the redundant 
> expression elimination.  The big blocker there was the tight integration 
> of DOM and threading.  But if Aldy can untangle that we can then 
> evaluate replacing DOM with FRE.

Once ranger does floats, I can't think of anything the forward threader 
could get that the backward threader couldn't.

> 
> 
>>
>> That said, it has one nice property it can leverage due to its incredibly
>> simple memory redundancy handling, in that it usually performs way less
>> alias queries than FRE (even when you run the latter in non-iterative 
>> mode).
> DOM as an infrastructure for optimization is probably reaching the end 
> of its useful life.  FRE has a lot more going for it.
> 
>>
>> But the same way DOM can register jump threading opportunities FRE
>> could do as well.
> I'd advise against that and instead look towards a model where no pass 
> has integrated jump threading and the only jump threading module we have 
> is the backwards threader.

Yes, please.  We need to separate jump threading from all passes.  One 
thing, and do it well.

Aldy