[LLVMdev] [RFC] Add compiler scheduling barriers

[Yi Kong]

On 19 June 2014 17:54, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 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.

atomic_thread_fence() always inserts a machine memory fence on weak
memory model, which is different from simply stopping reordering.
Memory fences are expensive and might be overkill.

We can leave this intrinsic out for now if it's not particularly
useful, as the in-line assembly hack does work, although not elegant.

> 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)?

__WFI() is just one of the instructions where reordering isn't
allowed. There are more examples in the DAI0321A document. I think it
might be required on other architectures as well.

>
> David
>