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.


> 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 

 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)

 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

 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,


Reply via email to