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

[Chris Lattner via llvm-dev]

> On Jun 23, 2018, at 11:48 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> 
> 
>> On Jun 23, 2018, at 11:35, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote:
>> 
>> 
>> 
>>> On Jun 23, 2018, at 11:27, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto: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.

Huh, ok, still seems dubious, but I’m certainly not opposed to making SmallVector<0> better!  Thanks Duncan,

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180623/2b59c2e3/attachment.html>