[llvm-commits] Avoid O(#registers*#basicblocks) memory use in LiveVariables

[Evan Cheng]

On May 22, 2009, at 9:07 PM, me22 wrote:

> 2009/5/22 Evan Cheng <evan.cheng at apple.com>:
>>
>> I can see the potential for both of those issues. Perhaps you can
>> specialize SparseBitVector with a smaller element size to reduce
>> memory usage? As for compile time cost, can you measure it by return
>> through the llvm test suite?
>>
>
> I'd be wary of decreasing the element size any more.
>
> I wrote up a quick test (attached) that suggests that on 64-bit linux
> only a third of the node is actually holding data right now. (The
> overhead from sparsity and linked list pointers is the other
> two-thirds.)  And on whatever platform codepad.org runs (I think VC++
> Win32), only a quarter of the memory is actually holding bits, and
> ElementSize could actually be increased to 160 without changing the
> amount of memory that new actually allocates per node.  32-bit linux
> seems to have the best ratio, with half of it useful.
>
> I don't know the pattern of sparsity in LiveVariables, but I'd
> actually argue for trying increasing it.
>
> Also, you might try using unsigned int for the BitWord in the
> SparseBitVectorElement (instead of unsigned long), as on 64-bit it
> would keep you from wasting the padding after the ElementIndex.  It
> should just involve changing the typedef, but could also slow things
> down a bit since Elements would no longer be a power of two.  No idea
> whether that'd be noticable over the pointer-following overhead,
> though.
>
> Or I suppose, depending on the way the numbering it implemented, it
> might be even better to have some kind of range container instead...

Thanks for doing the analysis. I think it all point to just leaving  
ElementSize along is probably fine.

Evan

>
>
> ~ Scott
> < 
> sbve_size_experiment 
> .cxx>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits