[LLVMdev] [RFC] Add compiler scheduling barriers

[Hal Finkel]

----- Original Message -----
> From: "Yi Kong" <kongy.dev at gmail.com>
> To: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, June 19, 2014 11:35:05 AM
> Subject: [LLVMdev] [RFC] Add compiler scheduling barriers
> 
> Hi all,
> 
> I'm currently working on implementing ACLE extensions for ARM. There
> are some memory barrier intrinsics, i.e.__dsb and __isb that require
> the compiler not to reorder instructions around their corresponding
> built-in intrinsics(__builtin_arm_dsb, __builtin_arm_isb), including
> non-memory-access instructions.[1] This is currently not possible.
> 
> 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?

I don't believe that we currently support calls that are terminators, and doing so would be a large change to the infrastructure. I think, however, that declaring an intrinsic that is marked such that mayHaveSideEffects() is true will also prevent reordering of anything around the intrinsic that touches observable state. Is there a reason why this would be insufficient?

 -Hal

> 
> Cheers,
> 
> Yi
> 
> ------
> 
> [1] A piece of code that requires such behaviour is:
> 
>   Data_array[n] = x; // memory access
>   __DSB();
>   __WFI();           // This cannot get executed until DSB completed
> 
> Moving WFI to before DSB will cause wrong behaviour. Code is taken
> from DAI0321A 4.14,
> (http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DAI0321A_programming_guide_memory_barriers_for_m_profile.pdf)
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory