================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
