[llvm-dev] Utilising no-unique-address

[David Blaikie via llvm-dev]

Hmm - though might this have problematic ABI implications? (If the
attribute isn't supported on all our supported compilers - then a
binary release of LLVM wouldn't be ABI compatible with all compilers?)

On Tue, Feb 9, 2021 at 9:52 AM Nathan James via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> About a month ago I pushed a patch to change BumpPtrAllocatorImpl to
> use the empty base optimization to reduce the size of the
> allocator(always a win). However looking at clangs support for the
> c++20 attribute `no_unique_address`, It appears that we support that in
> previous standards (including c++14).
>
> Can anyone see any issue to utilizing this attribute throughout the
> codebase behind a macro in `llvm/Support/Compiler.h`.
> `
> #if LLVM_HAS_CPP_ATTRIBUTE(no_unique_address)
> #define LLVM_NO_UNIQUE_ADDRESS [[no_unique_address]]
> #else
> #define LLVM_NO_UNIQUE_ADDRESS
> #endif
> `
>
> This approach is much cleaner than empty base classes and has fewer
> restrictions on the type.
>
> This feature is enabled in c++14 mode starting from clang(9.0.0),
> gcc(9.1) and icc(21.1.8). MSVC knows about the attribute since 19.15,
> but unfortunately there is no way to utilize it unless using
> `c++latest` mode. Fortunately, using the feature macro MSVC won't
> complain about this. I'm also uncertain on how clang-cl would handle
> this as it tries to maintain MSVC compatibility. It may be wise to also
> put this behind a _MSC_VER/_WIN32 flag as altering class layouts could
> cause some ABI compatibility issues.
>
> Thanks for reading,
> Nathan James
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev