[llvm-commits] Speeding up RegAllocLinearScan on big test-cases

Evan Cheng evan.cheng at apple.com
Wed May 7 09:54:33 PDT 2008


Can we hook up the llvm pool allocator to std::set and use it for the  
register allocator? It's simple and it made a huge difference on Mac  
OS X when we switched all LiveInterval VNInfo allocations to it.

Evan

On May 7, 2008, at 1:24 AM, Roman Levenstein wrote:

> Hi,
>
> 2008/5/7 Bill Wendling <isanbard at gmail.com>:
>> On Tue, May 6, 2008 at 3:31 PM, Evan Cheng <evan.cheng at apple.com>  
>> wrote:
>>> On May 6, 2008, at 6:13 AM, Roman Levenstein
>>
>>
>>>> But one thing about std::set that could be eventually interesting  
>>>> at
>>>> many places
>>>> is the following:
>>>> - in many situations we know the maximal size of the set in  
>>>> advance.
>>>> For example,
>>>>  in this patch, the set can contain at most all live intervals. In
>>>> the scheduler,
>>>>  the availableQueue can contain at most all SUnits. It means that
>>>> if we would
>>>>  be able to allocate the memory for the maximum possible number of
>>>> elements
>>>>  in advance, then there is no need for any additional memory
>>>> allocation.
>>>>
>>>> - I think, a custom STL allocator could be written that could do
>>>> exactly this. It would
>>>> reserve memory for the maximum number of elements (of the equal
>>>> size?)and
>>>> maintain a free list of cells. Then we can have a very efficient
>>>> allocation and sets
>>>> that do no produce to much malloc/free pressure. The same idea can
>>>> be used
>>>> also for some other STL containers.
>>>>
>>>> What do you think?
>>>
>>> I am not sure. I have little experience with custom STL allocators.
>>> Perhaps others will chime in. For now, using std::set is fine.
>>>
>> I created custom allocators before. They aren't that bad. You just
>> have to get the functionality correct (the allocators I created  
>> called
>> a malloc function that already had this functionality). The major
>> caveat is that if you don't have a well-tested memory manager
>> available, this can lead to nasty bugs. I would stick with std::set
>> unless it becomes a major albatross around our necks.
>
> I have a lot of experience with custom allocators. I extensively used
> them in the optimizing C compiler that  I have written few years ago
> for an embedded target. Initially I was using simple malloc/free and
> new/delete. Then I moved to GC, but at the end I switched to
> custom memory allocators. I can only save, that they had very positive
> impact on the performance of my compiler.
>
> Custom memory allocators are not such a black art, as it may seem at
> first glance, actually. And there are quite well proven allocators.
> Usually, they
> are not that complex and it is rather easy to see if they are correct.
> Normally, they are used for node-based STL containers or for most
> typical nodes created by the compiler (e.g. SDNode, SDOperand,  
> SUnit, etc).
> And they can really speed-up things, e.g. if they use pool  
> allocation or
> segregated storage or if they free all the objects at once.
> For example, imagine that we use such an allocator for SUnit nodes.  
> Then
> it may reserve memory for N SUnit objects and very quickly allocate  
> it.
> Once scheduling is over, all such objects can be freed at once, just  
> by
> cleaning/deleting the custom allocator.
>
> I'm currently experimenting with 4-5 different custom STL allocators
> I have found on the Internet. Once I have representative figures to  
> compare
> them again STL's standard allocators and after I cleaned up the code,
> I'll report about it to this mailing list.
>
> -Roman
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list