[llvm-commits] [cfe-commits] [PATCH] ARM strexd and ldrexd intrinsics

[Jim Grosbach]

On May 25, 2011, at 1:09 AM, Renato Golin wrote:

> On 25 May 2011 04:20, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote:
>> I see no reason for it go in another separated patch, because it's a
>> requirement, if it's not in pairs, the instruction is wrong.
> (...)
>> I lower both of them, the former using tablegen, the later in iseldag.
>> I have no plans to add the others, the only reason I'm trying to add
>> this one is because there's no way to represent the pair restriction
>> using inline asm.
> 
> Ok, just checking. ;)
> 
> 
>> Because of that, I still think that would be good to have a "ldrexd"
>> and "strexd" around. But I'm open to any better approach, if there's
>> one available.
> 
> Yes, I know. My idea was to use @llvm.atomic.load.i64 (rather than
> load.add.i64) to map to the same concept.
> 
> I don't know if other architectures have the atomic load/store
> instructions, but if they do, it makes sense to be generic.

PPC does.

This gets ugly for ARM because i64 isn't a legal type, but we have these 64-bit instructions. So it's hard to match them effectively.

For additional builtins that map directly to ldrex/strex, which I'm given to understand ARM's compiler supports, we would indeed need new intrinsics (one for each data size).

We also want to use these instructions for the 64-bit versions of the __sync* builtins. Those currently generate a libcall, but they don't really need to.

-Jim