[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

[Devin Jeanpierre via Phabricator via cfe-commits]

devinj.jeanpierre created this revision.
devinj.jeanpierre added reviewers: rsmith, aaron.ballman, rjmccall, ahatanak.
Herald added a subscriber: dexonsmith.
devinj.jeanpierre requested review of this revision.
Herald added a project: clang.

This change enables library code to skip paired move-construction and
destruction for `trivial_abi` types, as if they were trivially-movable and
trivially-destructible. This offers an extension to the performance fix offered
by `trivial_abi`: rather than only offering trivial-type-like performance for
pass-by-value, it also offers it for library code that moves values but not as
arguments.

For example, if we use `memcpy` for trivially relocatable types inside of
vector reallocation, and mark `unique_ptr` as `trivial_abi` (via
`_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI` / `_LIBCPP_ABI_UNSTABLE` / etc.),
this would speed up `vector<unique_ptr>::push_back` by 40% on my benchmarks.
(Though note that in this case, the compiler could have done this anyway, but
happens not to due to the inlining horizon.)

If accepted, I intend to follow up with exactly such changes to library code,
including and especially `std::vector`, making them use a trivial relocation
operation on trivially relocatable types.

D50119 <https://reviews.llvm.org/D50119> and P1144 <https://reviews.llvm.org/P1144>:

This change is very similar to D50119 <https://reviews.llvm.org/D50119>, which was rejected from Clang. (That
change was an implementation of P1144 <https://reviews.llvm.org/P1144>, which is not yet part of the C++
standard.)

The intent of this change, rather than trying to pick a winning proposal for
trivial relocation operations, is to extend the behavior of `trivial_abi` in a
way that could be made compatible with any such proposal. If P1144 <https://reviews.llvm.org/P1144> or any
similar proposal were accepted, then `trivial_abi`,
`__is_trivially_relocatable`, and everything else in this change would be
redefined in terms of that.

Safety:

It's worth pointing out, specifically, that `trivial_abi` already implies
trivial relocatability in a narrow sense: a `trivial_abi` type, when passed by
value, has its constructor run in one location, and its destructor run in
another, after the type has been trivially relocated (through registers).

Trivial relocatability optimizations could change the number of paired
constructor/destructor calls, but this seems unlikely to matter for
`trivial_abi` types.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114732

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/attr-trivial-abi.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D114732.390435.patch
Type: text/x-patch
Size: 17224 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20211129/92c74d83/attachment-0001.bin>