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

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/9/2021 3:21 AM, Aldy Hernandez wrote:
>
>>
>>    /* If this path does not thread through the loop latch, then we are
>>       using the FSM threader to find old style jump threads. This
>>       is good, except the FSM threader does not re-use an existing
>>       threading path to reduce code duplication.
>>
>>       So for that case, drastically reduce the number of statements
>>       we are allowed to copy.  */
>
> *blink*
>
> Woah.  The backward threader has been using FSM threads 
> indiscriminately as far as I can remember.  I wonder what would break 
> if we "fixed it".
?!?  I'm not sure what you're suggesting here.  If you s/FSM 
threader/backwards threader/ in the comment does it make more sense?   
The term FSM really should largely have been dropped as the backwards 
threader was improved to handle more cases.




>
>>
>> so these cases should use the "old style" validity/costing metrics 
>> and thus
>> classify threading opportunities in a different way?
>
> Jeff, do you have any insight here?
This is precisely what you're cleaning up.


>
>>
>> I think today "backwards" vs, "forwards" only refers to the way we find
>> threading opportunities.
>
> Yes, it's a mess.
>
> I ran some experiments a while back, and my current work on the 
> enhanced solver/threader, can fold virtually everything the 
> DOM/threader gets (even with its use of const_and_copies, avail_exprs, 
> and evrp_range_analyzer), while getting 5% more DOM threads and 1% 
> more overall threads.  That is, I've been testing if the path solver 
> can solve everything the DOM threader needs (the hybrid approach I 
> mentioned).
>
> Unfortunately, replacing the forward threader right now is not 
> feasible for a few reasons:
Right.  But I thought the short term goal was to replace/remove the 
forward threading from VRP.   Dropping from DOM is going to be tougher.

>
> a) The const_and_copies/avail_exprs relation framework can do floats, 
> and that's next year's ranger work.
Right.  I'd actually run into this as well when I wanted to drop all the 
range bits out of DOM and rely exclusively on EVRP.   It'd still be a 
step forward to rip out the EVRP engine from DOM and simplify all the 
code that derives one equivalence from another so that it's only working 
on FP values.

>
> 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.
Right.  This is a prerequisite.  Though some of the costing will need to 
be conditional on the threader being used.  Refer back to the discussion 
around how the forward threader can commonize thread paths that lead to 
the same destination while the backwards threader can not.

>
> c) DOM changes the IL as it goes.  Though we could conceivably divorce 
> do the threading after DOM is done.
The only reason threading runs in parallel with DOM is so that it can 
use the context sensitive equivalences.  With the infrastructure you're 
building, there's a reasonable chance we can move to a model where we 
run DOM (and in the long term a simpler DOM) and threading as distinct, 
independent passes.

Jeff