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

[Alfredo Dal'Ava Júnior via Phabricator via llvm-commits]

adalava added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71600