> 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. */
...
> 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.
> ;; 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")])
Emitting just that alone isn't enough though. The first attempt
I made did that and failed because the whole
reg-restore
reg-restore
tie (mem blockage only)
sequence was allowed to move past the stack pointer reset when
it's performed as a mere register to register move.
So I ended up adding the clobber mem:blk scratch to the existing
tie parallel, which references the stack pointer register as
well so is forbidden to move past it's update.
Olivier
