[libcxx-commits] [libcxx] [lldb] [libcxx] adds a size-based representation for `vector`'s unstable ABI (PR #155330)

[Christopher Di Bella via libcxx-commits]

================
@@ -462,19 +468,24 @@ class vector {
   _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI void push_back(value_type&& __x) { emplace_back(std::move(__x)); }
 
   template <class... _Args>
-  _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI
+  _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI __emplace_back_result_t emplace_back(_Args&&... __args) {
----------------
cjdb wrote:

> Now, regarding whether we can avoid setting `__end = __emplace_back_slow_path(std::forward<_Args>(__args)...);` from this function, I think we'd want to check the codegen before and after. IIRC, the idea was to make the flow of data explicitly visible to the compiler because it allowed it to generate better code (that's why we didn't call `back()` again in the pre-refactor version).
> 
> We're on the same page that the new code is better in the sense of readability and reuse, but we had decided to make a conscious readability tradeoff since this function is very performance sensitive.
> 
> Now, if we find out that we can avoid the `_end = __emplace_back_slow_path(...)` without hurting code generation (I'd be surprised because something would have had to change), that means we can avoid bifurcating `__emplace_back`. Otherwise, I'd bifurcate it for the size/pointer based vector layouts and accept it as tech debt.

I modified the above experiment to look at [what happens when I toggle this change](https://carbon.godbolt.org/z/WMG1qT5G3) (you'll want to look for `IMPLICIT_SET_END`). I'm by no means an expert in assembly, but it looks like we get simpler codegen in both implementations across all experiments to me, when we stop assigning `__end` in `emplace_back`?

https://github.com/llvm/llvm-project/pull/155330