This is an archive of the discontinued LLVM Phabricator instance.

[COFF, ARM64] Implement InterlockedCompareExchange*_* builtins
ClosedPublic

Authored by mgrang on Nov 2 2018, 5:39 PM.

Diff Detail

Repository
rC Clang

Event Timeline

mgrang created this revision.Nov 2 2018, 5:39 PM
rnk added inline comments.Nov 5 2018, 11:40 AM
include/clang/Basic/BuiltinsARM.def
270

Given how much duplication there is, I think we need to have some kind of BuiltinsMSVC.def that contains a list of all the interlocked builitin families, like this:

INTERLOCKED_BUILTIN(_InterlockedCompareExchange)
INTERLOCKED_BUILTIN(_InterlockedOr)
INTERLOCKED_BUILTIN(_InterlockedAnd)

We'd include this file here, with INTERLOCKED_BUILTIN defined as:

#define INTERLOCKED_BUILTIN(Op) \
  TARGET_HEADER_BUILTIN(Op##8_acq, "ccD*cc", "nh", "intrin.h", ALL_MS_LANGUAGES, "") \
  TARGET_HEADER_BUILTIN(Op##8_nf, "ccD*cc", "nh", "intrin.h", ALL_MS_LANGUAGES, "") \
...

That'll stamp out the enums that we need, and then we can reuse the .def file to reduce duplication in the switch/case below.

Every op is basically 16 operations: {8, 16, 32, 64} X {seq_cst, rel, acq, nf}

I'm not sure what to do about the ones that overlap with x86.

mgrang added inline comments.Nov 5 2018, 12:32 PM
include/clang/Basic/BuiltinsARM.def
270

Thanks Reid. Yes, I think we can certainly cleanup further. That being said, can we get these patches committed first and then cleanup in a follow-up patch?

rnk added inline comments.Nov 5 2018, 2:19 PM
include/clang/Basic/BuiltinsARM.def
270

Fair enough. I think the approach you have in all of these patches is reasonable and not hard to clean up later. I don't have time to review each IR implementation right now, but it is important to get a second opinion, because as you've seen they have had bugs (missing fences) in the past.

lib/CodeGen/CGBuiltin.cpp
262–265

I don't know enough about the memory model to really say if this is right, so I'll pass the buck to @efriedma.

efriedma added inline comments.Nov 5 2018, 3:56 PM
lib/CodeGen/CGBuiltin.cpp
236

Please rename this function; it's very confusing to have both EmitAtomicCmpXchgValue and MakeAtomicCmpXchgValue which do almost the same thing, but expect the arguments in the opposite order.

262–265

This is equivalent to what you'd get for the C++ a.compare_exchange_strong(x, y, memory_­order​::​release), which should match general intuition about "release" operations. (There are only three possible failure orderings: seq_cst, acquire, and monotonic.)

mgrang updated this revision to Diff 172675.Nov 5 2018, 4:23 PM
mgrang marked an inline comment as done.
efriedma accepted this revision.Nov 5 2018, 4:26 PM

LGTM

This revision is now accepted and ready to land.Nov 5 2018, 4:26 PM
This revision was automatically updated to reflect the committed changes.