https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jeffrey A. Law from comment #9) > > > > 1 2 3 > | \ / > | 4 > | / \ > +->5 6 > / \ > 7 8 > > > Note how BB4 does not dominate BB5. If we try to thread something like > 2->4->5->?, then can't we run into problems with the equivalence handling as > well, even though we're not dealing with a loop? Well, if the top of the path does not dominate an element of the path.. then maybe yes. The way it currently works, the assumption is that each node of the path dominates the previous node. and for processing the path itself, this should be fine since we add relations as we walk the path and its a linear path. The problem with back edges was we start to see the same SSA name a second time... which is really bad karma and we really need to reset the path relations immediately. The next problem which you point out is when a relation does not occur in the path. Then we query from the top of the path using ranger. So if the top of the path does not dominate some element of the path, and we make a query from there, then yes, we are open to an possible issue if we make a ranger query. Otherwise I think we are OK because we are simply walking the path and by definition the earlier elements of the path dominate the next one. . Perhaps the rule should be... if the next block is not dominated by the path root, reset all relations, and reset the root to the common dominator of the original root and the new node? OR perhaps thats too aggressive and we reset path relations only on back edges, and reset the root to the common dominator whenever we encounter a node not dominated by the path start?
