On Fri, Apr 15, 2016 at 07:05:25PM +0200, Olivier Hainque wrote: > > 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. > > Yes, that's exactly the kind of problem we're fighting and, indeed, > the memory barrier alone isn't enough. > > Here, the idea is to add a memory barrier to the set of things that the rs6000 > back-end already does, which tries to be better than a complete scheduling > barrier (see rs6000_emit_stack_tie), but turns out to still fail in some > corner > cases due to alias analysis intricacies (original problem description at > the very beginning of this now long thread: > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01337.html)
I think the best thing to do is add the clobber-of-mem-scratch to the final stack deallocate (as a parallel). I don't see anything else that will work reliably. Segher
