[PATCH] Implement low-level ARM ldrex/strex intrinsics

[JF Bastien]

>> In practice I believe CPUs implement the exclusive monitors at the
>> level of the cache line, and "unrelated" loads and stores are not
>> allowed to interfere by the specification. On a CPU like this, the
>> only way LLVM could interfere would be with a spill to a stack slot on
>> the same cache line as the atomic variable being accessed.
>
> That's much less scary than you made it sound originally.  That isn't too bad.

I'm not sure about that. I think the monitor can be by set, so you can
cause a self-deadlock quite easily by storing in a ldrex/strex loop.

>> Also, these already exist in other compilers (and ours!) which make no
>> more guarantees than we do as far as I'm aware. That doesn't
>> necessarily mean we should follow, but it might suggest the issues are
>> surmountable.

Shouldn't you use something like this for the intrinsic (borrowing
from some NaCl code I'm playing with):
def int_nacl_atomic_load : Intrinsic<[llvm_anyint_ty],
    [LLVMPointerType<LLVMMatchType<0>>, llvm_i32_ty],
    [IntrReadWriteArgMem]>;

I think all your intrinsics need IntrReadWriteArgMem, to act more like barriers.

I may also be missing something obvious, but how does the Clang part
handle alignment? It'll fail when the pointer isn't naturally aligned.
I don't know if you have sufficient information to at least catch some
of this issue.

Also, ldrex/strex can be reg-imm on Thumb, I don't think you allow
this? I'm not sure you'd want to, and I guess SelectionDAG should be
able to fold the immediate into the address.