------- Comment #4 from jakub at gcc dot gnu dot org 2010-05-19 19:23 -------
Yes, it is related, but solving it in the scheduler in generic way isn't going
to be trivial.
E.g. x86_64 emits memory_blockage early in ix86_expand_epilogue:
/* See the comment about red zone and frame
pointer usage in ix86_expand_prologue. */
if (frame_pointer_needed && frame.red_zone_size)
emit_insn (gen_memory_blockage ());
Another testcase:
extern void *alloca (__SIZE_TYPE__);
__attribute__((noinline, noclone))
long *bar (long *p)
{
asm volatile ("" : : "r" (p) : "memory");
return p;
}
long
foo (long x)
{
long *p = (long *) alloca (x * sizeof (long));
long *q = bar (p);
return q[0];
}
which shows that some blockage or preventing scheduling over the stack release
is needed even when the frame size is smaller than the red zone size and that
the memory address doesn't need to be obviously based on stack pointer (it
would be just safe to allow moving over stack accesses that are provably in the
red zone or above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
