This is third in a series of patches to move intrinsic definitions out of intrin.h.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
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. |
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? |
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. |
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.) |
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:
We'd include this file here, with INTERLOCKED_BUILTIN defined as:
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.