http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #34 from Jeffrey A. Law <law at redhat dot com> 2011-02-07 16:27:24
UTC ---
Typically the right thing to do is to block all memory motions across a change
in the stack pointer. It's somewhat overly pessimistic, but in reality the
few motions lost aren't going to be performance critical.
In the past each backend has emitted the blockage/barrier and it typically
happened soon after the port was converted to use RTL prologues/epilogues...
That's probably the main reason why this was never fixed in the scheduler
itself -- the first couple ports emitted a blockage and after that it became
normal practice.
I would support both emitting the suitable blockage insn in the ARM backend or
adding a dependency between the stack pointer adjustment insn and all memory
insns in the scheduler. Either is IMHO acceptable given history. The first
would be slightly preferred during this late stage of development with the
latter being more appropriate in early stage development.
