[libcxx-commits] [PATCH] D63744: In the libc++ unstable ABI, use [[no_unique_address]] instead of __compressed_pair when available.

Tue Nov 10 07:25:53 PST 2020

ldionne added a comment.

In D63744#2385752 <https://reviews.llvm.org/D63744#2385752>, @mclow.lists wrote:

> In D63744#2385750 <https://reviews.llvm.org/D63744#2385750>, @jyknight wrote:
>
>> Hm, that might indeed be feasible. We'll need to potentially insert padding both before the first type and after the second type, but we can static_assert the correctness against the old layout, so that's not _too_ scary.
>>
>> If we go this route, it will mean that libc++ is only usable in an ABI-stable manner on Clang 9+ or GCC 9+. On earlier compilers, and on MSVC, the attribute is ignored, and the layout will thus be incorrect/incompatible. Is it viable to require those compiler versions to both build and use libc++? The LLVM build itself only requires GCC 5+/Clang 3.5 at the moment, so that would mean we'd need to start requiring the use of the 2-stage "runtimes" build in order to build libc++, at the least.

I think this is entirely reasonable. I actually have a draft email I want to send to discuss the issue of libc++ compiler support, but its relevance is gated on making progress with the unified standalone build discussed at http://lists.llvm.org/pipermail/libcxx-dev/2020-October/001004.html.

TLDR: It's already wrong to build libc++ with older compilers if you truly care about ABI and having a robust setup, since those are not tested AND they can't always build the library properly (e.g. libc++abi might be missing RTTI for some fundamental types). I think a 2 stage runtimes build should be the default way that libc++ is built as part of releasing a toolchain. This is what libstdc++ does w/ GCC.

> At which point, we should be asking ourselves, "is this worth doing?"

I think it's a good question, however according to my answer to the above, my personal opinion is that it's worth exploring, if there are true benefits to be had from using `[[no_unique_address]]`. I think the benefits are real.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63744