Page MenuHomePhabricator

[AArch64] Codegen for FEAT_LRCPC3
ClosedPublic

Authored by tmatheson on Tue, Jan 10, 2:00 PM.

Details

Summary

Implements support for the following 128-bit atomic operations with +rcpc3:

  • store-release
  • store-release volatile
  • load-acquire
  • load-acquire volatile
  • load-acquire const
  • load-acquire const volatile

D126250 and D137590 added support for emitting LDAPR (Load-Acquire RCPc) rather
than LDAP (Load-Acquire) when +rcpc is available. This patch allows emitting
the 128-bit RCPc instructions added in FEAT_LRCPC3 LDIAPP/STILP. The
implementation is different from LDAPR, because there are no non-RCPc
equivalents for these new instructions.

Support for the offset variants will be added in a later patch.

Diff Detail

Event Timeline

tmatheson created this revision.Tue, Jan 10, 2:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptTue, Jan 10, 2:00 PM
tmatheson requested review of this revision.Tue, Jan 10, 2:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptTue, Jan 10, 2:00 PM

You need FEAT_LSE2 if you're going to generate STILP/LDIAPP from a 128-bit access, in order to get single-copy atomicity.

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
5711

Outdated?

22488

Yes that sounds reasonable

llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
1211
tmatheson updated this revision to Diff 491788.Tue, Jan 24, 7:28 AM
tmatheson marked 3 inline comments as done.

Require LSE2

lenary accepted this revision.Wed, Jan 25, 3:55 AM
This revision is now accepted and ready to land.Wed, Jan 25, 3:55 AM
This revision was landed with ongoing or failed builds.Wed, Jan 25, 4:28 AM
This revision was automatically updated to reflect the committed changes.
efriedma added inline comments.
llvm/test/CodeGen/AArch64/Atomics/aarch64_be-atomic-load-rcpc3.ll
283

Sort of orthogonal to this change, but can someone at ARM verify if this is the sequence we actually want for sequentially consistent loads with lse2, as opposed to using caspal? (I'm a bit concerned given the issues we ran into with narrower widths on Windows; see D141748.)