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

[me22]

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...

~ Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbve_size_experiment.cxx
Type: text/x-c++src
Size: 742 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090522/7381319a/attachment.cxx>