[LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities

[Tim Northover]

> The easiest solution would be to extend the cmpxchg instruction with a
> weak variant.  It is then trivial to map load, modify, weak-cmpxchg to
> load-linked, modify, store-conditional (that is what weak cmpxchg was
> intended for in the C[++]11 memory model).

That would certainly be the easiest. But you'd get less scope for
optimising control flow around the instructions (say an early return
on failure or something). I think quite a bit can be done if LLVM
*really* knows what's going to be going on with these atomic ops on
LL/SC architectures.

>> I don't suppose you have any plans to port Mips to the IR-level LL/SC
>> expansion? Now that the infrastructure is present it's quite a
>> simplification (r206490 in ARM64 for example, though you need existing
>> target-specific intrinsics at the moment). It would be good to iron
>> out any ARM-specific assumptions I've made.
>
> I'd rather avoid it, because it doing it that late precludes a lot of optimisations
> that we're interested in.  I'd much rather extend the IR to support them at a
> generic level.

I think you might be misinterpreting what the change actually is.
Currently the expansion happens post-ISel (emitAtomicBinary and
friends building the control flow and MachineInstrs directly).

This moves it to before ISel but still late in the pipeline (actually,
you could even put it earlier: I didn't because of fears of opaque
@llvm.arm.ldrex intrinsics pessimising mid-end optimisations).
Strictly earlier than what happens now, and a reasonable
stepping-stone to generic load-linked instructions or intrinsics.

In my experience, CodeGen has improved with the change. ISelDAG gets
to make use of more information when choosing how to do the operation:
values already known to be sign/zero extended, immediates, etc.

Tim.