[llvm-dev] RFC: Should SmallVectors be smaller?

[Sean Silva via llvm-dev]

On Sat, Jun 23, 2018 at 11:48 AM, Duncan P. N. Exon Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Jun 23, 2018, at 11:35, Duncan P. N. Exon Smith <dexonsmith at apple.com>
> wrote:
>
>
>
> On Jun 23, 2018, at 11:27, Duncan P. N. Exon Smith <dexonsmith at apple.com>
> wrote:
>
> The patch LGTM, but why would someone actually have a SmallVector with N =
> 0?  Isn’t that a vector?
>
>
> It's a vector that can be passed as a SmallVectorImpl parameter.  But
> yeah, mostly misguided.
>
>
> There's another explanation given in llvm/include/llvm/ADT/IndexedMap.h:
> ```
> template <typename T, typename ToIndexT = identity<unsigned>>
>   class IndexedMap {
>     using IndexT = typename ToIndexT::argument_type;
>     // Prefer SmallVector with zero inline storage over std::vector.
> IndexedMaps
>     // can grow very large and SmallVector grows more efficiently as long
> as T
>     // is trivially copyable.
>     using StorageT = SmallVector<T, 0>;
>
> ```
>
>
> And another explanation in r266909, along the same lines:
>
>     IR: Use SmallVector instead of std::vector of TrackingMDRef
>
>     Don't use std::vector<TrackingMDRef>, since (at least in some versions
>     of libc++) std::vector apparently copies values on grow operations
>     instead of moving them.  Found this when I was temporarily deleting the
>     copy constructor for TrackingMDRef to investigate a performance
>     bottleneck.
>
>
>
See also https://reviews.llvm.org/rL175906
It seems that a POD SmallVector can use realloc(3) to grow, which can just
twiddle page tables for large POD vectors.

-- Sean Silva


>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180623/21a90a91/attachment.html>