On Wed, Jan 19, 2022 at 7:41 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > 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.
Ah, that's an interesting approach to solving this issue! > > 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) Thanks for the explanation. > Its on my task list to document the entire oracle mechanism for both > equivalences and relations in the next month or two. That would be welcome. Thanks, Richard. > > Andrew >
