[llvm-commits] [llvm] r169157 - /llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp

[Peter Cooper]

On Dec 3, 2012, at 1:44 PM, Michael Ilseman <milseman at apple.com> wrote:

> 
> On Dec 3, 2012, at 1:41 PM, Bill Wendling <wendling at apple.com> wrote:
> 
>> On Dec 3, 2012, at 1:34 PM, Michael Ilseman <milseman at apple.com> wrote:
>> 
>>> On Dec 3, 2012, at 1:33 PM, Bill Wendling <wendling at apple.com> wrote:
>>> 
>>>> On Dec 3, 2012, at 1:29 PM, Michael Ilseman <milseman at apple.com> wrote:
>>>> 
>>>>> Author: milseman
>>>>> Date: Mon Dec  3 15:29:36 2012
>>>>> New Revision: 169157
>>>>> 
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=169157&view=rev
>>>>> Log:
>>>>> Since this SmallVector immediately grows on the next line, don't waste stack space. SmallVector is still needed due to existing APIs growing their arguments
>>>>> 
>>>> Why not make the size 256*1024 instead of 0?
>>>> 
>>> 
>>> That is an alternate possibility, though that number seems awfully big. What are the general guidelines for trade-offs like these?
>>> 
>> I guess there's stack space to consider. However, if it's not an issue, it's probably better to use the constant size. But I'll leave it up to you. 262144 bytes is pretty big…
>> 
> 
> Just talked to Jakob, he agrees that that is way too much stack space to use.
Also, using a large small vector would likely just lead to a very large memcpy later if we grow past the small vector size, which might be the case in practice, i'm not sure.

It would be nice to start at something smaller, 8KB perhaps, but have some way of saying that if we grow, jump straight to 256KB like the current behavior starts at.

Pete
> 
> 
>> -bw
>> 
>> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits