On 04/14/2016 09:47 AM, Andreas Krebbel wrote:
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))?
I thought we had code to handle this case specially, but I can't
immediately find it in sched-deps.c.
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")])
;; Do not schedule instructions accessing memory across this point.
(define_expand "memory_blockage"
[(set (match_dup 0)
(unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]
""
{
operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
MEM_VOLATILE_P (operands[0]) = 1;
})
(define_insn "*memory_blockage"
[(set (match_operand:BLK 0)
(unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]
""
""
[(set_attr "length" "0")])
Jeff
