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

[Bill Wendling]

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.

-bw