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

[Chris Lattner via llvm-dev]

> On Dec 1, 2020, at 4:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> Can you spell this out for me?  Why do we need noexcept if we’re building with -fno-exceptions?  What is going on here?
> 
> Sure. It's a bit convoluted. Here's my understanding:
> 
> First, here's why std::vector has this behaviour:
> - std::vector grow operations need to transfer their existing elements over to the new storage.
> - The grow operations are usually required to meet the "strong exception guarantee": if something throws, this function has no effect.
> - If move operations throw, you can't provide this guarantee unless you copy (you can't move back the elements that have been half-moved over, in case another exception is thrown; but if it was just a copy, the original storage still has the elements safely unmodified).
> - There's a caveat / carve out, that if T cannot be copy-constructed AND T's move constructor is not noexcept, then the guarantee is waived (since there's no way to implement it).
> - Implementation is to call std::move_if_noexcept (https://en.cppreference.com/w/cpp/utility/move_if_noexcept <https://en.cppreference.com/w/cpp/utility/move_if_noexcept>), which moves if it's a noexcept operation, or if T is not copy-constructible.
> 
> Second, here's why the behaviour doesn't change when -fno-exceptions:
> - -fno-exceptions does NOT imply `noexcept` (maybe it should?, but it doesn't).
> - This is implemented by detecting via SFINAE whether something is `noexcept` (maybe std::vector::resize/push_back/etc should have a special case? but that's controversial).
> 
> IMO, until all the C++ standard libraries and host compilers that we support being built with will consistently use std::move on grow operations in std::vector in -fno-exceptions mode, we should only use std::vector when we absolutely have to. It's not designed for -fno-exceptions codebases

Wow, thank you for the great explanation.  I agree with you that this seems like a pretty credible reason why we can’t depend on every host std::vector to do what we need, so we should use something like an llvm::Vector.

Two thoughts:

1) are you, or anyone else, interested in driving an llvm::Vector proposal + coding standard change to get us going in the right direction?  I don’t think we need a mass migration of the code base, just get the policy aligned right plus the new type name to exist.

2) I think we should pursue Richard’s proposal or something like it to make Clang provide better C++ performance out of the box.  I assume that all the STL containers will have similar issues (not to mention user defined ones), and noexcept isn’t widely used.  Some flag that turns noexcept on by default (or for everything even with an exception spec?) in -fno-exceptions mode seems like a great thing to do.

-Chris


> .
> 
> (
> There's some discussion in this thread:
> http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000344.html <http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000344.html>
> 
> And Richard had a proposal that made sense to me:
> http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000343.html <http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000343.html>
>> I'm wondering if we should have an experimental
>> option to specify that functions are noexcept by default (overridable
>> by an explicit exception specification)
> 
> 
> But that only fixes it in host compilers that implemented this experimental mode.
> )

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