[LLVMdev] [RFC] Add compiler scheduling barriers

[Tim Northover]

Hi Yi,

>> If all you want is a compiler barrier with the existing fence semantics
>> w.r.t. reordering, we could consider extending fence with a "compiler only"
>> (bikeshed needed!) attribute.
>
> AFAIK, there isn't an existing fence strong enough for the memory
> barrier intrinsics. The current strongest fence still allows
> register-register data-processing instructions reordering across. For
> DSB and ISB, no instruction should be allowed.

I disagree. DSB and ISB may need to be insulated against reordering
with other instructions with unmodelled side-effects (e.g. MSR/MRS),
but they don't care about a normal instructions. There's no reason the
compiler shouldn't be free to move an arithmetic add around them, for
example. Fortunately, I think LLVM already handles this.

The main argument I'm aware of in favour of stronger barriers is for
things like performance counters where the intervening instructions
are sometimes critical to what's being measured. I'm not entirely
convinced by that either, since I don't think the compiler can ever
provide the needed guarantees anyway.

>> Why would your barrier need to be a basic block terminator?  That doesn't
>> parse for me.  Could you explain?
>
> Compiler shouldn't allow instructions to be reordered between basic
> blocks. By implementing as a basic block terminator, it will stop any
> instruction from reordering.

It should, and does. The idealised view is that basic blocks should be
no extra barrier at all to reordering. Of course, we don't reach that
because the control-flow is harder to analyse so it's simply easier to
do optimisations within a basic block.

But you shouldn't be taking that as a point of principle when
designing anything.

Cheers.

Tim.