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

[Chris Lattner via llvm-dev]

On Jun 21, 2018, at 9:16 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> Something like this could definitely work, but most smallvectors are on the stack.  They are intentionally used when sizeof(smallvector) isn’t important, so I don’t think this optimization will pay off.
> 
> For better or worse (mostly worse), there are a ton of SmallVector fields in data structures, including some even nested inside other SmallVectors (e.g., see the cleanup in r235229).  Often these data structures are heap-allocated.

Egads, that seems like a big issue, and (most of the time, but perhaps not always) a misuse of SmallVector.  It seems that this should be fixed, instead of changing smallvector.

>> Out of curiosity, what brings this up?
> 
> I've noticed that Clang is using more stack recently (we're seeing more crashes from template recursion; it seems the template recursion limit needs to shrink), and somehow that train of thought led to this.
> 
> I share your skepticism that it will help stack usage much, but SmallVector/SmallVectorImpl is so ubiquitous, it could help the heap a bit.  And if it doesn’t hurt runtime performance in practice, there’s no reason to fork the data structure.
> 
> If no one has measured before I might try it some time. 

I’m not familiar with the modern structure of the code, but is there any chance these algorithms can be reworked to be iterative instead of recursive?  Shrinking individual frames may buy some time, but isn’t really a fix.

-Chris

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