[libcxx-commits] [PATCH] D152208: [libc++] Introduce __make_uninitialized_buffer and use it instead of get_temporary_buffer

Nikolas Klauser via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Jun 27 13:51:53 PDT 2023


philnik added a comment.

In D152208#4452378 <https://reviews.llvm.org/D152208#4452378>, @hans wrote:

> In D152208#4448532 <https://reviews.llvm.org/D152208#4448532>, @hans wrote:
>
>> We're hitting CFI errors in Chromium after this, see https://github.com/llvm/llvm-project/issues/63523
>
> Friendly ping to make sure this doesn't get lost in the other discussion.

I'm working on adding a CFI run to our CI right now. It looks like I just have to add `_LIBCPP_NO_CFI` to `__make_uninitialized_buffer`, given that `get_temporary_buffer` also has that attribute. I hope to get the patch completed by tomorrow.

In D152208#4453582 <https://reviews.llvm.org/D152208#4453582>, @davidxl wrote:

> Should we partially revert this change? Instead of making use of the new interface for stable_sort, the old  get_temporary_buffer can be used (as an internal API), until the performance parity is reached?

I don't see why. If the allocation is actually so costly that it dominates `stable_sort`, you should either look into whether you actually need `stable_sort` for your workload or look into getting a better allocator (TCMalloc is probably not bad, so I suspect that's not the problem). Sorting doesn't seem like a task where a single allocation should ever dominate. I'd also like to see the actual use case where a single branch is so problematic that it warrants a revert before doing so. I don't even know how much of an impact this patch actually is in your specific use-case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152208/new/

https://reviews.llvm.org/D152208



More information about the libcxx-commits mailing list