[LLVMdev] [RFC] Add compiler scheduling barriers

Yi Kong kongy.dev at gmail.com
Thu Jul 3 05:28:41 PDT 2014


On 3 July 2014 12:52, Tim Northover <t.p.northover at gmail.com> wrote:
> On 3 July 2014 12:04, Yi Kong <kongy.dev at gmail.com> wrote:
>> After some internal discussions, we concluded that moving
>> non-memory-access and non-side-effect instructions around memory
>> barrier intrinsics is fine in almost any typical situation. In the
>> rare occasions where reordering is undesirable, the programmer should
>> use inline asm instead.
>
> I'm curious now. What situations did you come up with where inline asm
> would be needed?

A key use of ISB is where the access or cacheability semantics of the
instruction stream being executed may change (e.g. updating MPU or MMU
access attributes, enabling or disabling caches) and you want to force
the pipeline to be flushed and refilled with fetches against the new
configuration. If the instruction immediately follows is a simple
instruction, you have to use inline asm.

Also, for self-modifying code, reordering around ISB can be
problematic. But you probably needs to write it in asm in the first
place anyway.

-Yi



More information about the llvm-dev mailing list