diff options
| author | JF Bastien <jfb@chromium.org> | 2013-08-01 15:06:01 -0700 |
|---|---|---|
| committer | JF Bastien <jfb@chromium.org> | 2013-08-01 15:06:01 -0700 |
| commit | a7665e96f34c4a981d59c78b0b872b8f0b100cb9 (patch) | |
| tree | aa05a7a1f915980654ae61c5a2f5952abfc7e561 /docs | |
| parent | b9657234ee8b1951db5977a8ffb55a2e5df6d76c (diff) | |
Add Intrinsic::nacl_atomic_is_lock_free
This is part of a bigger CL to fix C++11 in PNaCl, to commit in the following order:
- https://codereview.chromium.org/20552002
- https://codereview.chromium.org/20554002
- https://codereview.chromium.org/20560002
- https://codereview.chromium.org/20561002
This should be the last PNaCl ABI change for C11/C+11 atomic support.
Note that Clang already has a builtin for lock-free, but it's partly resolved by Clang's ExprConstant.cpp and CGBuiltin.cpp, whereas what we want is a call that becomes a constant at translation-time. I made the translation part fairly general so it's easy to support architectures where ``true`` isn't always the right answer.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
TEST= ./scons run_synchronization_cpp11_test --verbose bitcode=1 platform=x86-64
TEST= ninja check-all
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/20554002
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/PNaClDeveloperGuide.rst | 2 | ||||
| -rw-r--r-- | docs/PNaClLangRef.rst | 12 |
2 files changed, 13 insertions, 1 deletions
diff --git a/docs/PNaClDeveloperGuide.rst b/docs/PNaClDeveloperGuide.rst index b0a47423e3..9c27ae5c14 100644 --- a/docs/PNaClDeveloperGuide.rst +++ b/docs/PNaClDeveloperGuide.rst @@ -53,7 +53,7 @@ relates memory locations to each other as the C11/C++11 standards do. As in C11/C++11 some atomic accesses may be implemented with locks on certain platforms. The ``ATOMIC_*_LOCK_FREE`` macros will always be ``1``, signifying that all types are sometimes lock-free. The ``is_lock_free`` methods will return -the current platform's implementation at runtime. +the current platform's implementation at translation time. The PNaCl toolchain supports concurrent memory accesses through legacy GCC-style ``__sync_*`` builtins, as well as through C11/C++11 atomic primitives. diff --git a/docs/PNaClLangRef.rst b/docs/PNaClLangRef.rst index 027f33ac92..75218a0c02 100644 --- a/docs/PNaClLangRef.rst +++ b/docs/PNaClLangRef.rst @@ -488,3 +488,15 @@ in ``"llvm/IR/NaClAtomicIntrinsics.h"``. operations as well as some legacy GCC-style ``__sync_*`` builtins while remaining stable as the LLVM codebase changes. The user isn't expected to use these intrinsics directly. + +.. code-block:: llvm + + declare i1 @llvm.nacl.atomic.is.lock.free(i32 <byte_size>, i8* <address>) + + The ``llvm.nacl.atomic.is.lock.free`` intrinsic is designed to + determine at translation time whether atomic operations of a certain + ``byte_size`` (a compile-time constant), at a particular ``address``, + are lock-free or not. This reflects the C11 ``atomic_is_lock_free`` + function from header ``<stdatomic.h>`` and the C++11 ``is_lock_free`` + member function in header ``<atomic>``. It can be used through the + ``__nacl_atomic_is_lock_free`` builtin. |