[PATCH] D71600: PowerPC 32-bit - forces 8 byte lock/lock_free decisions at compiled time

Mon Jan 13 10:16:37 PST 2020

jfb added a comment.

In D71600#1816834 <https://reviews.llvm.org/D71600#1816834>, @adalava wrote:

> In D71600#1816160 <https://reviews.llvm.org/D71600#1816160>, @MaskRay wrote:
>
> > I am still confused why you need the special rule for `__atomic_is_lock_free` (GCC/clang) and `__c11_atomic_is_lock_free` (clang).
> >
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/builtins.c#L7300-L7314 GCC `__atomic_is_lock_free` expands to either 1 or a library call to `__atomic_is_lock_free`, never 0. How did FreeBSD get around libatomic when it was still using GCC? In clang, We can probably extend the semantics of `__c11_atomic_is_lock_free` and use `clang::TargetInfo::getMaxAtomicPromoteWidth`, but I'll make more research in this area.
> >
> > Can you be elaborate how do `__atomic_is_lock_free`/`__c11_atomic_is_lock_free` pull in libatomic.{a,so} dependency on FreeBSD powerpc?
>
>
> On FreeBSD 11.x/12.x (GCC4), libatomic can be installed by user through "gcc9" ports package. The library is not shipped with the base system and it's not required to compile the base system (world + kernel) since nothing depends on 64 bit atomics an external call so `__atomic_is_lock_free` is never made.
>
> The problem appeared when I switched to clang in a new ISO, this added an undesired external libatomic dependency to build FreeBSD base sources (world): clang was emitting a call to external `__atomic_is_lock_free` implementation when building clang itself from base sources. (user would need to install gcc9 to be able to build FreeBSD base source using clang, it's not acceptable.

I'm curious about this: what part of clang makes it emit a call to `is_lock_free`? clang itself probably shouldn't be doing this, so maybe we should fix that issue as well.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71600/new/

https://reviews.llvm.org/D71600