<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style>On Wed, Jan 2, 2013 at 10:38 AM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:jolesen@apple.com" target="_blank" class="cremed">jolesen@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>

<br>
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.<br>
</blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote>
<div><br></div><div style>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?</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Second, specialize Recycler::clear(BumpPtrAllocator) to avoid doing the same thing with the free list.<br></blockquote><div><br></div><div style>If the above works, this might tag along for free?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Please review!<br>
<span class="HOEnZb"><font color="#888888"><br>
/jakob<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div></div>