[libcxx-commits] [PATCH] D128146: [libc++] Use uninitialized algorithms for vector

[Konstantin Varlamov via Phabricator via libcxx-commits]

var-const added a comment.

In D128146#3703883 <https://reviews.llvm.org/D128146#3703883>, @eaeltsin wrote:

> In D128146#3703292 <https://reviews.llvm.org/D128146#3703292>, @var-const wrote:
>
>> In D128146#3703008 <https://reviews.llvm.org/D128146#3703008>, @ldionne wrote:
>>
>>> In D128146#3699909 <https://reviews.llvm.org/D128146#3699909>, @vitalybuka wrote:
>>>
>>>>> @vitalybuka This isn't unexpected. `-fno-inline` disables inlining, which is essential for a lot of other optimizations. Using `-fno-inline` pretty much defeats the optimizer: https://godbolt.org/z/zrE5o1WK1.
>>>>
>>>> I am more concerned about sanitizers
>>>>
>>>> https://godbolt.org/z/1x9qjGG19 Near LBB11_5 we have now __asan_memcpy per every "P", before it was for entire vector.
>>>> I assume some additional improvement in instrumentation are possible, maybe replacing fixed short asan_memcpy with check/load/store. Or even optimizing asan_memcpy itself.
>>>>
>>>> But still maybe some ideas if it's solvable on libc++ level so we rely less on optimizations?
>>>
>>> I suspect this might go away if we manually lowered `std::uninitialized_foo` to `memcpy` like we do for `std::copy` and `std::move`.
>>
>> (Just in case, I had a patch to do that a while ago: https://reviews.llvm.org/D118329)
>
> I'm curious to check if this resolves some of the problems we are having now... @var-const, is your patch still applicable at head?

Unfortunately, the patch hasn't been rebased for a few months. That part of the code base hasn't changed much in the meantime, but it's likely the patch won't apply cleanly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128146