[llvm-dev] RFC: [SmallVector] Adding SVec<T> and Vec<T> convenience wrappers.

Chris Lattner via llvm-dev
2020-12-01T22:19:27Z

>>> On Nov 17, 2020, at 1:42 PM, David Blaikie <dblaikie at
gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>>>> Thoughts/suggestions:
>>>>> - Adding the default seems very reasonable to me, and I
think that 64 bytes is a good default.  I think you should change the behavior
so that SmallVector<LargeThing> defaults to a single inline element
instead of zero though.  Perhaps generate a static_assert when it is crazy
large.
>>>>
>>>> Out of curiosity: Why a single rather than zero?
>>>
>>> My rationale for this is basically that SmallVector is typically
used for the case when you want to avoid an out-of-line allocation for a small
number of elements, this was the reason it was created.  While there is some
performance benefits of SmallVector<T,0> over std::vector<> they are
almost trivial.
>>
>> The performance benefits aren't trivial.
>>
>> std::vector grow operations will refuse to use std::move for some T, a
pessimization required by its exception guarantees, even if you're building
with `-fno-exceptions`. We had a massive compile-time problem in 2016 related to
this that I fixed with 3c406c2da52302eb5cced431373f240b9c037841 by switching to
SmallVector<T,0>. You can see the history in r338071 /
0f81faed05c3c7c1fbaf6af402411c99d715cf56.
>>
>> That issue, at least, is fixable without switching from std::vector
just by adding noexcept to the appropriate user-defined move constructors.
>
> Sure, once we’ve added noexcept to all types in LLVM/Clang/etc. That’s a
pretty long tail though; a lot of work for relatively little gain given that we
don’t care about exceptions anyway and we have an optimized vector
implementation in tree.

Can you spell this out for me?  Why do we need noexcept if we’re building with
-fno-exceptions?  What is going on here?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/fbb568d8/attachment.html>