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

[Jeffrey Yasskin]

On Mon, May 25, 2009 at 7:30 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> 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.

Thanks! I'll submit the AliveBlocks part now then, since you've
removed UsedBlocks.

Jeffrey