On 04/14/2016 11:10 AM, Olivier Hainque wrote:
On 14 Apr 2016, at 18:50, Jeff Law <l...@redhat.com> wrote:
I thought we had code to handle this case specially, but I can't immediately
find it in sched-deps.c.
Unless I misunderstood what you were exactly looking for,
the special code is in alias.c. E.g. write_dependence_p:
/* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
This is used in epilogue deallocation functions. */
*That's* the one I was looking for :-)
...
Some ports also use an unspec_volatile to achieve the same effect:
;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and
;; all of memory. This blocks insns from being moved across this point.
(define_insn "blockage"
[(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)]
""
""
[(set_attr "length" "0")])
Yes, I pondered this one and thought that a memory barrier
would be less aggressive, while good enough.
But don't you run the risk that the stack could be deallocated before
the restores are done? This came up on the PA port a long time ago.
IIRC the situations was something like this:
We had a frame pointer and all the restores were being done via the
frame pointer. So the scheduler moved the stack pointer adjustment up
past the register restores. At which point the restores were reading
from unallocated stack space.
99.99% of the time it didn't cause a problem. But if we got an
interrupt in that brief window, boom, the interrupt handler could
allocate a frame on the current stack, store some data in there which
clobbered the saved register state.
Jeff
