On 04/11/2016 12:15 PM, Olivier Hainque wrote: > >> On Mar 28, 2016, at 19:41 , Richard Henderson <r...@redhat.com> wrote: >> >> But I expect for stage4, the best solution is to strengthen the stack_tie >> pattern to block all memory. Early scheduling of the stack frame >> deallocation (a simple logic insn) can't really be that important to >> performance. > > Something like the attached patch, at least for next stage1 until the > more general issue is sorted out ? > > Only basic testing at this point. I can do more if considered appropriate. > > Thanks for your feedback, > > With Kind Regards, > > Olivier > > * config/rs6000/rs6000.c (rs6000_emit_stack_tie): Add a > (clobber mem:BLK (scratch)) to the set of effects, blocking > all memory accesses.
We have the same problem on S/390 and I'm also looking for a way to solve that. I'm not sure about the (clobber (mem)) approach. Wouldn't it be theoretically possible to move a memory write over a (clobber (mem))? The patch I'm currently testing follows a proposal from Joseph Myers in 2011: https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00977.html + [(set (mem:BLK (scratch)) + (unspec:BLK [(match_operand:BLK 0 "memory_operand" "+m")] UNSPEC_TIE))] What I'm wondering is whether the memory read is actually needed here?! Wouldn't the following have the same effect? [(set (mem:BLK (scratch)) (unspec:BLK [(const_int 0)] UNSPEC_TIE))] To my understanding this should block memory reads and writes from being moved across. The MEM probably should be set up to be in the frame alias set? Bye, -Andreas-
