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

Roman Levenstein romix.llvm at googlemail.com
Wed May 7 01:24:25 PDT 2008


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



More information about the llvm-commits mailing list