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

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f1a601fe88f99d52ca80617266897b217bcd4d64
      https://github.com/llvm/llvm-project/commit/f1a601fe88f99d52ca80617266897b217bcd4d64
  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