Hello Alan, On Apr 6, 2012, at 02:32 , Alan Modra wrote: [...] > In the epilogue, the previous frame read must be prevented from moving after > the stack adjust. If the adjacent write/read uses r1 as a base reg, > then we don't need a stack tie at all.
Right > Writes/reads further away won't be reordered over the adjacent > write/read. At least, I've never seen gcc do so, even with older > versions known to have bugs in aliasing analysis. Ah, I hadn't understood that there was this implicit assumption. I understand better that part of the logic then. (would be worth a comment IMHO) Thanks! > (Hah! In writing this, I remember why I took out that assert. What > happens prior to the tie in the prologue is of no concern.) :-) I have been able to verify that your patch helps our previously failing case, starting from the svn rev and failure mode analyzed per http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html. We get through the same compiler circuits, down to base_alias_check now with x = (unspec:SI [ (reg/f:SI 1 1) (reg/f:SI 31 31) (reg:SI 11 11) ] UNSPEC_TIE) instead of (reg:SI 1). x_base is now null and such that we rapidly conclude that "we don't know anything about aliasing", so the outer mem accesses are declared conflicting. Have you discovered where the problem you are still observing is coming from (with another case on 4.4) ? I was planning to look into it and realized that maybe you were already doing so. Thanks much for your feedback, Olivier
