[LLVMdev] [RFC] Add compiler scheduling barriers

[David Chisnall]

On 19 Jun 2014, at 11:35, Yi Kong <kongy.dev at gmail.com> wrote:

> It is sometimes useful to prevent the compiler from reordering
> memory-access instructions as well. The only way to do that in both
> GCC and LLVM is using a in-line assembly hack:
>  asm volatile("" ::: "memory")
> 
> I propose adding two compiler scheduling barriers intrinsics to LLVM:
> __schedule_barrier_memory and __schedule_barrier_full. The former only
> prevents memory-access instructions reordering around the instruction
> and the latter stops all. So that __isb, for example, can be
> implemented something like:
>  inline void __isb() {
>    __schedule_barrier_full();
>    __builtin_arm_isb();
>    __schedule_barrier_full();
>  }
> 
> To implement these intrinsics, I think the best method is to add
> target-independent pseudo-instructions with appropriate
> properties(hasSideEffects for memory barrier and isTerminator for full
> barrier) and a pseudo-instruction elimination pass after the
> scheduling pass.
> 
> What do people think of this idea?

C11 defines the atomic_thread_fence() function for the memory-only part.  Clang exposes this as __c11_atomic_thread_fence().  This is more flexible than that part of your proposal, as it allows relaxing the restrictions based on the memory model.

I can see the use case for preventing any reordering, but it seems somewhat specialised.  Wouldn't it be simpler to just model the wfi operation as loading from memory (which, effectively, it does, if you have a memory-mapped interrupt controller)?

David