On Mon, May 27, 2013 at 10:20 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman <era...@google.com> wrote: >> On Sat, May 25, 2013 at 4:46 AM, Richard Biener >> <richard.guent...@gmail.com> wrote: >>> Easwaran Raman <era...@google.com> wrote: >>> >>>>In that case, if my insert_stmt immediately follows dep_stmt and both >>>>have the same UID, not_dominated_by would return true and I will end >>>>up updating insert_stmt to dep_stmt which is wrong. >>> >>> But there should be a safe default answer for >>> Equal uids. Unless we are asking different questions in different places. >>> Thus, I do not like the stmt walking but rather have a safe fallback. >> >> I am lost here. I don't see how we could avoid doing the stmt walking >> to resolve the equal uid case. How to ensure that not_dominated_by (a, >> b) returns true and not_dominated_by (b, a) returns false if A and B >> have the same UID and A appears before B without doing the statement >> walk. And, I don't see why the statement walk is bad. It is not likely >> that there is a long sequence of statements with the same UID. > > Sure, but if you are always asking a question like "is placing X before Y ok?" > then you can conservatively answer "no" and code should handle that ok. > If you are asking questions both way then of course no conservative answer is > possible. Both current uses of not_dominated_by are of the same kind, > if the placement is not ok then either the insert point needs adjustment or > the debug stmt reset.
Ok, thinking about this more I come to the conclusion that a safe default for equal UIDs is not possible as we may be not able to order two dep_stmts. I still dislike walking though, but to get the quite frequent regressions fixed the patch is ok as-is. Please install. Thanks, Richard.
