SmallVector::grow/swap should be shared for POD T's

[lattner]

Bugzilla Link	3758
Resolution	FIXED
Resolved on	Dec 16, 2009 02:44
Version	1.0
OS	All

Extended Description

Looking at the exported symbol map of a couple of tools, I see a ton of things like this:

   llvm::SmallVectorImpl<clang::ProgramPoint>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::QualType>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::Selector>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::SourceLocation>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::Stmt*>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::StringLiteral*>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::SwitchStmt*>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::Token>::grow(unsigned long)
   llvm::SmallVectorImpl<clang::Token>::operator=(llvm::SmallVectorImpl<clang::Token> const&)

These are all POD types, and there is no reason for them to all get their own copy of these (somewhat large) methods. We only need to instantiate grow/swap etc when T requires copy ctors etc.

[llvmbot]

Elaboration on the above:

23:23 < sabre> SmallVector is a template
23:23 < sabre> grow is a method in it
23:23 < sabre> (smallvector is analogous to std::vector)
23:23 < sabre> grow is large, so it is not inlined
23:24 < sabre> because it's in a template, the template gets instantiated for lots of different T's and the code is not shared
23:24 < sabre> this leads to code bloat
23:24 < sabre> make sense?
23:24 < djc> yes, makes sense so far
23:25 < djc> so you want to put it outside of the template, right?
23:25 < sabre> yeah. a good way to do it would be to have a SmallVectorImpl base class
23:25 < sabre> which is non-templatized
23:25 < sabre> and all the big non-polymorphic stuff could be sunk into it
23:25 < sabre> this is how SmallPtrSet works for example

[lattner]

This is done, in a series of patches leading up to r91529