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 and P1144:
This change is very similar to D50119, which was rejected from Clang. (That change was an implementation of 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 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.
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.