Re: [PATCH] tree-optimization/103721 - Only add equivalencies that are still valid.

[Andrew MacLeod <amacleod@redhat.com>]

On 1/19/22 04:33, Richard Biener wrote:
> On Wed, Jan 19, 2022 at 2:37 AM Andrew MacLeod via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> OK for trunk?
> OK.  I don't quite understand how what you describe above works, it sounds
> a bit odd with respect to the idea that equivalences should be transitive but
The transitive check is what prevents us from having to find and update 
all the equivalence sets when a name needs to be removed.  we can simply 
create a new equivalence with that name, and all the older equivalences 
in the dom tree will no longer equate with it and are eliminated by the 
query.  With the nature of on-demand, its possible for equivalences to 
get created in unexpected orders, and logging all the equivalences as 
they are seen and leaving the final determination to query time seems to 
be the easiest and most accurate way to get results.  I suspect we miss 
a few relations if we process things in a  random order, but we 
shouldn't get anything wrong.
> I should note that forming equivalences from PHI nodes with backedges
> is not possible without being very careful since you will easily end up
> equating _1 and _1 from different iterations (and thus with different value).

The dominator search version used by ranger won't create equivalences 
from back edges normally because the back edge doesn't dominate the 
block.  The only time we could get an equivalence from a back edge would 
be if all the other arguments to a PHI at the top of the loop were 
undefined, or the same value as came in on the back edge

ie

top_5 = PHI<val_6(2), val_6(8)>  would create an equivalence between 
top_5 and val_6...   but that's OK because it is just a copy then anyway.

or

top_5 = PHI <undefined(2), val_6(8)>

This will create an equivalence between top_5 and val_6 in the loop, 
until we reach the point where val_6 is defined, and then the 
equivalence will get killed.  its possible that might cause an issue in 
a single BB loop, If I could reproduce that...  let me experiment.  In 
which case I'll simply disable equivalences applied to PHIs if its 
driven by just a back edge.

I dont see any other way we can get an equivalence/relation from a back 
edge with the oracle (other than what the threader does, it has its own 
oracle extensions for paths)

Its on my task list to document the entire oracle mechanism for both 
equivalences and relations in the next month or two.

Andrew