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

[JF Bastien]

>> 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.
>
> A lot of it's implementation-defined (in the CPU implementer's sense
> of the word), but it's apparently (ARMARM A3.4.3) Memory_address[31:a]
> where 3 <= a <= 11. I don't see any reference to allowing the decision
> to be made by set.

Hah, you seem to be correct. I though the top bits could also be
dropped from the monitor, but the doc you pointed at clearly say that
the worst-case is 512 words in the same monitor. Couldn't that still
be an issue because the tag is on physical address (so the stack could
happen to alias with a lock)?

> I really want about the most conservative interpretation possible. I
> thought that was with no specifier (though admittedly only from the
> vagueish documentation). In particular just reading and writing
> argument memory is too weak, in my opinion. They shouldn't be
> reordered with other ldrex/strex intrinsics even if LLVM can prove
> that there's no overlap in the addresses.

I'm interested in other's opinions on this too :)

> I'm not sure what you mean. The address can accept an offset on 32-bit
> Thumb2, which I do account for (and make use of, and test) with the
> new ComplexPattern. Is there some other way they can make use of an
> immediate?

I completely missed that test. Right you are.