[LLVMdev] llvm atomics on 64-bit values

[Reid Kleckner]

We're already using std::atomic<> in Clang:

$ ack 'std::atomic' | cat
lib/Basic/VirtualFileSystem.cpp:843:  static std::atomic<unsigned> UID;
lib/Frontend/ASTUnit.cpp:214:static std::atomic<unsigned>
ActiveASTUnitObjects;
lib/Frontend/CompilerInvocation.cpp:1956:  static std::atomic<unsigned>
GraveYardSize;
tools/libclang/CIndexCodeCompletion.cpp:319:static std::atomic<unsigned>
CodeCompletionResultObjects;

I'd use it for pointer-sized values.  I probably wouldn't use it on
uint64_t, since that'll probably give some 32-bit toolchain somewhere
heartburn.


On Tue, Jun 3, 2014 at 12:45 PM, Zachary Turner <zturner at google.com> wrote:

> I need an atomic pointer exchange, so I took a look at Support/Atomic.h,
> and the only supported types are 32-bit values.  I can't figure out an
> obvious reason for this other than perhaps nobody ever had need of this
> yet, but given that this is kind of a low level thing, I thought I should
> ask first.  Is there any reason I should not add 64-bit versions of the
> atomic functions?
>
> Additionally, the function I need looks like __sync_test_and_set() on GNU,
> for which the documentation has this to say:
>
> Many targets have only minimal support for such locks, and do not support
> a full exchange operation. In this case, a target may support reduced
> functionality here by which the *only* valid value to store is the
> immediate constant 1. The exact value actually stored in *ptr is
> implementation defined.
>
> Does anyone happen to know the details here?  Is this true on any platform
> we support?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140603/d0fe51c9/attachment.html>