Displaying 5 results from an estimated 5 matches for "__atomic_always_lock_free".
2019 Mar 12
1
Handling of __c11_atomic_is_lock_free({1, 2, 4, 8}) in compiler-rt atomic.c
...return __atomic_load_8(..)
/* otherwise lock-based implementation */
}
That is fine if an __atomic_is_lock_free() is provided and it always returns false for 8 (BTW __atomic_is_lock_free is not implemented in compiler-rt), but this wastes code size and is inefficient.
Should atomic.c be calling __atomic_always_lock_free instead of __c11_atomic_is_lock_free to check for lock-free cases? The “always” flavor is determined at compile time.
OR should the front-end always lower __c11_atomic_is_lock_free() to true or false for atomics on objects of size 1, 2, 4, or 8 bytes?
AND /OR should some sort of new TargetInfo r...
2016 Jan 27
7
Adding sanity to the Atomics implementation
...d 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 -- can also use it? Or...just...
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
...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 -- ca...
2016 Jan 31
2
Adding sanity to the Atomics implementation
...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 -- can al...