Re: [PATCH] Support threading of just the exit edge

[Andrew MacLeod <amacleod@redhat.com>]

On 8/18/22 03:08, Richard Biener wrote:
>
>> The caveat is that it is only a partial solution... it will only work for
>> names on that stmt.  if you have anything more complex, ie
>>
>> if (a == 0 || b == 0)  we have a seqeunce feeding the ctrl stmt..
>>
>> c_1 = a == 0
>> c_2 = b == 0
>> c_3 = c_1 && c_2
>> if (c_3 == 0)
>>
>> only the evaluation of c_3 will have the ctrl stmt as its context.. the others
>> will be evaluted on their own statement, and thus neither a nor b would pick
>> up anything from the block as they are evalauted and cached as they are
>> seen.    unless of course we are doing a walk :-P
> Hmm, but as I traced it when I do range_of_expr the context stmt I provide
> will be passed down and even when processing dependences that context
> will stick?  But maybe it doesn't because it would mean explosion of the
> cache?
>
> But yeah, with the above restriction it would be even more useless.
> Same issue as with
>
>    *p = 0;
>    if (..)
>     / \
>   ..   \
>        if (p)
>
> here the local adjustment of 'p' in if (p) would not pick up the
> p != 0 guarantee from the immediate dominator.

it certainly should. the earlier BB will have the ~[0, 0] property in 
the on-exit structure, so when the range of 'p' is evaluated on the edge 
to the next block, it will be adjusted. the value for on-entry of P to 
that block will therefore be ~[0, 0].   Ranger does this, and the path 
query code is *suppose* to.. late discussions with Aldy yesterday left 
me unclear if it always does.  it should.  that was the entire point of 
leaving the on-demand filling of the structure via immediate uses.



>>   In the meantime,
>> it should be possible to take a ranger that just completed a VRP pass, and use
>> that as the root ranger for a threading pass immediately after.. I think there
>> may be some lingering issues with abnormal edges if we "re-visit" blocks which
>> we claim to have walked due to the way I store inferred ranges in those
>> block.. (the expectation being we never go back up into the block, so the
>> on-entry cache works like the "current def" vector in the original EVRP.  I'd
>> have to think about that too.
> Of course that would essentially do a VRP pass before each threading
> which I think is a bit expensive.  Also looking at how ranger works
> with all its abstraction having the "old" EVRP style body walk rather
> than abusing the on-demand ranger for such a walk would be a lot more
> efficient for this purpose :/

No, I just meant when we do the VRP pass, rather than throw away the 
fully primed ranger and its values, one could invoke the threader using 
it...  But I'm not sure how much extra we'd get anyway.


>>> Meanwhile I'm leaning towards calling this a phase ordering issue
>>> of threading + VRP, but that also means we shouldn't deliberately
>>> try to preserve "threadings" of this kind - in fact we might want
>>> to explicitely reject them?
>> we are probably going to want to visit some pass ordering.
> Sure, though there's never going to be a good enough pass ordering :/
>
> Richard.