[llvm-commits] [PATCH] Add an iplist::clearAndLeakNodesUnsafely() function, speed up Recyler:clear()

[Chandler Carruth]

On Wed, Jan 2, 2013 at 10:38 AM, Jakob Stoklund Olesen <jolesen at apple.com>wrote:

> Hi,
>
> I am trying to speed up the ~MachineFunction destructor. We are currently
> wasting a lot of time and memory bandwidth by pointlessly visiting and
> changing all the instructions in the function before the BumpPtrAllocator
> gives its pages back to the OS.
>
> I am eventually going to make all MachineInstr memory be allocated from
> the same BumpPtrAllocator so the whole MachineFunction data structure can
> be taken down by flushing the allocator. This is similar to Apache's memory
> pools.
>

This makes total sense to me with one exception: I think we need to
predicate it on the node's destructor being trivial. Otherwise we're
violating the design contract of the class, even if we correctly deallocate
the memory backing the objects.


>
> As a first step, I need to convince an iplist to let go of its contents
> without pulling every object into cache (and dirtying all the cache lines
> as a bonus!). The clearAndLeakNodesUnsafely() function added in the first
> patch does that.


I feel like I would like this more if it were more generically applied.
What do you think about making this a compile time policy decision for the
ilist?

I'm imagining a bool template parameter which essentially says
"LeakSubobjects" and which is a compile error if used in conjunction with a
value type with non-trivial destructor.

Then, clear(), erase(), replace(), and other methods on ilist which
currently spend time walking the ilist and deallocating can all benefit
from the fast-path.


> Second, specialize Recycler::clear(BumpPtrAllocator) to avoid doing the
> same thing with the free list.
>

If the above works, this might tag along for free?


>
> Please review!
>
> /jakob
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130102/9471bb31/attachment.html>