> On Apr 15, 2016, at 18:42 , Jeff Law <l...@redhat.com> wrote: >> /* (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 :-)
:-) >> 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. 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) Olivier
