On Tue, May 28, 2013 at 4:11 AM, Richard Biener <richard.guent...@gmail.com> wrote: > 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.
Thanks. Submitted the patch at r199385. - Easwaran
