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

[Bruno Cardoso Lopes]

Hi Renato,

> I'm not proficient enough in the regalloc to analyse that part, but
> regardless of the intrinsic lowering, I think that's an important
> change on itself (maybe on a separate patch?).

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.

> But I was wondering about the need for an intrinsic...
>
> First, you declare both ldrexd and strexd but only lowers the former.
> Are you planning to implement both? And the single/half/word variants,
> too?

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.

> Second, I couldn't find ldrex and strex intrinsics, but the
> instructions are clearly there. If they were there just for
> disassembly purposes, than we need to be able to lower them somehow.

There are no ldrex and strex of any type indeed.
Remember that there's also the assembling purpose, not only disassembly.

> I was wondering if @llvm.atomic.load couldn't trigger LDREX in armv6+
> platforms without the need to create new intrinsic...

You say, for something like __sync_fetch_and_add(ptr, 0), right? That
would make sense, but the problem is that LDREX it's not the only
instruction that would be generated. When you use
__sync_fetch_and_add_4 for example, mem barrier calls are generated
before and after llvm.atomic.load.add.i32.p0i32, and this is the
assembly result:

  mov r12, #0
  dmb sy
.LBB0_1:
  ldrex r1, [r0]
  add r2, r1, r12
  strex r3, r2, [r0]
  cmp r3, #0
  bne .LBB0_1
  mov r0, r1
  dmb sy
  bx  lr

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.
Thanks for the feedback

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc