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