llvm dev - Jul 2014 - [LLVMdev] [RFC] Add compiler scheduling barriers

Hi Philip,
> Aside: From the documentation, it's actually unclear how strong a
barrier
> ISB actually is.  The "fetched after the ISB" gives a lot of room
for
> interpretation.  (i.e. is it legal for a cpu to fetch every instruction in
a
> function, queue them for execution under wait conditions, *then* fetch the
> ISB?  This would be a *really* weird implementation, but would it be legal
> according to this spec?  If so, the ISB provides *no* guarantees.)
>
> Reference:
>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGHHIE.html
You've actually linked to the assembler (as in "armasm") reference
manual there. The architectural documentation of these barriers is
better, though still not airtight in my opinion. From section A3.8.3,
the bit about "program order" is new, and it's after the ISB has
*completed*:

"An ISB instruction flushes the pipeline in the processor, so that all
instructions that come after the ISB instruction in program order are
fetched from cache or memory only after the ISB instruction has
completed."

It's behind a registration wall, but the v7 version can be had as a
.pdf here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html

Cheers.

Tim.

On 06/27/2014 09:46 AM, Tim Northover wrote:
> Hi Philip,
>
>> Aside: From the documentation, it's actually unclear how strong a
barrier
>> ISB actually is.  The "fetched after the ISB" gives a lot of
room for
>> interpretation.  (i.e. is it legal for a cpu to fetch every instruction
in a
>> function, queue them for execution under wait conditions, *then* fetch
the
>> ISB?  This would be a *really* weird implementation, but would it be
legal
>> according to this spec?  If so, the ISB provides *no* guarantees.)
>>
>> Reference:
>>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGHHIE.html
> You've actually linked to the assembler (as in "armasm")
reference
> manual there. The architectural documentation of these barriers is
> better, though still not airtight in my opinion. From section A3.8.3,
> the bit about "program order" is new, and it's after the ISB
has
> *completed*:
Figured there had to be something better, but that's what google found 
me.  Thanks.
>
> "An ISB instruction flushes the pipeline in the processor, so that all
> instructions that come after the ISB instruction in program order are
> fetched from cache or memory only after the ISB instruction has
> completed."
Not seeing the full text, this still looks incomplete.  I think we can 
infer what was actually meant here, so it doesn't make much of a 
practical difference.
>
> It's behind a registration wall, but the v7 version can be had as a
> .pdf here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html
Also behind a registration wall.  I might bother find my old account 
info at some point, but not right now.

Philip

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.

Thus I'm dropping this RFC. Thanks for your comments.

-Yi