[all-commits] [llvm/llvm-project] d64394: [libc++] Always query the compiler to find whether...

[Louis Dionne via All-commits]

  Branch: refs/heads/release/15.x
  Home:   https://github.com/llvm/llvm-project
  Commit: d64394b81d6e9d7a97a08fb1c6b42a24d2847b6c
      https://github.com/llvm/llvm-project/commit/d64394b81d6e9d7a97a08fb1c6b42a24d2847b6c
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2022-09-19 (Mon, 19 Sep 2022)

  Changed paths:
    M libcxx/docs/ReleaseNotes.rst
    M libcxx/include/atomic
    M libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp
    M libcxx/test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp

  Log Message:
  -----------
  [libc++] Always query the compiler to find whether a type is always lockfree

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.

After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).

However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.

This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.

Fixes #57440

Differential Revision: https://reviews.llvm.org/D133377

(cherry picked from commit f1a601fe88f99d52ca80617266897b217bcd4d64)