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

[Bill Wendling]

I don't think I was suggesting that they were a mysterious or poorly
understood. Just that because they are non-trivial, they could be the
source of even more bugs if we try to create our own. Please use them
if you have an existing one that works well.

-bw

On Wed, May 7, 2008 at 1:24 AM, Roman Levenstein
<romix.llvm at googlemail.com> 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
>