Displaying 5 results from an estimated 5 matches for "__atomic_is_lock_free".
2019 Mar 12
1
Handling of __c11_atomic_is_lock_free({1, 2, 4, 8}) in compiler-rt atomic.c
...) will expand into an inlined sequence of instructions. Therefore, we get what we want which is an optimized implementation of __atomic_load_8().
But, let’s say the target is an ARM variant that does not support atomics for 8-byte objects. The front-end will lower __c11_atomic_is_lock_free(8) to __atomic_is_lock_free(8) (note the “is” vs “always”) which is not lowered to “false” but instead remains as a function call. __c11_atomic_load_8() is then lowered to a function call __atomic_load_8() since we are not inlining atomic operations on 8-byte objects. The result is code like this:
void __atomic_load_8(…)
{...
2016 Jan 27
7
Adding sanity to the Atomics implementation
...of AtomicExpandPass and in ISel). When choosing whether to inline or libcall, only the size and alignment of the operation should be considered, and not the operation itself, or the type. This will ensure that the "all or none" property is adhered to.
(Q: what about the implementation of __atomic_is_lock_free/__atomic_always_lock_free in clang? The clang frontend can't query target information from the llvm backend, can it? Is there some other way to expose the information of what sizes are supported by a backend so that the clang builtins -- the latter of which must be a C++ constant expression --...
2016 Jan 28
1
[cfe-dev] Adding sanity to the Atomics implementation
On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote:
> I think Clang should continue to duplicate this information, the same way
> we duplicate target datalayout strings. Other than that, sure, we can let
> LLVM expand IR operations to libcalls. I don't immediately see a problem
> with that.
Note that a libcall doesn't necessarily mean using locks. With
2016 Jan 28
0
Adding sanity to the Atomics implementation
...When choosing whether to inline or libcall, only the size
> and alignment of the operation should be considered, and not the
> operation itself, or the type. This will ensure that the "all or none"
> property is adhered to.
>
> (Q: what about the implementation of
> __atomic_is_lock_free/__atomic_always_lock_free in clang? The clang
> frontend can't query target information from the llvm backend, can it?
> Is there some other way to expose the information of what sizes are
> supported by a backend so that the clang builtins -- the latter of
> which must be a C++...
2016 Jan 31
2
Adding sanity to the Atomics implementation
...en choosing whether to inline or
> libcall, only the size and alignment of the operation should be
> considered, and not the operation itself, or the type. This will
> ensure that the "all or none" property is adhered to.
>
>
> (Q: what about the implementation of
> __atomic_is_lock_free/__atomic_always_lock_free in clang? The clang
> frontend can't query target information from the llvm backend, can
> it? Is there some other way to expose the information of what sizes
> are supported by a backend so that the clang builtins -- the latter
> of which must be a C++ con...