<div class="gmail_quote">On Mon, May 14, 2012 at 11:23 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On May 5, 2012, at 12:54 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
> I wanted to start the initial review on a pass I've been working on. It's essentially doing hot/cold partitioning, cold region extraction, function splitting, or cold region outlining. Whatever terminology you would like, you get the idea. It's a really simple pass, built entirely out of all the existing infrastructure (some of which I've been cleaning up to let everything fall out this easily).<br>

><br>
> While this won't do a whole lot of interesting things on its own, I'm preparing to tweak the inline cost heuristics in a way that will allow this to form the essence of partial inlining. We can run this before inlining, splitting large cold regions of code into separate functions, and then be able to inline the remainder more easily.<br>

><br>
> I haven't run benchmarks, and this patch doesn't turn the pass on, I just want to get initial feedback, and get the code into the shape where I can put it in-tree, and then look at turning it on if benchmarks prove positive.<br>

<br>
</div>Chandler,<br>
<br>
Very nice.<br>
<br>
I'm dismayed that you depend on RegionInfo, but it is understandable. We could probably improve RegionInfo to be more efficient and self-contained (no DomFrontier), but I think we'd be much better off dropping RegionInfo and handling SEME regions. AFAIK CodeExtractor can already handle that. Is there any particular reason you need RegionInfo other than finding a connected set of blocks dominated by a cold block? Can FunctionSplitter just find its own regions?<br>
</blockquote><div><br></div><div>I'm dismayed that RegionInfo is still in the tree and not being improved. ;] I think we should fix RegionInfo to be efficient and reasonably well implemented. It as *already* handling SEME regions except for the "ME" case of function returns (something that is trivial to fix).</div>
<div><br></div><div>Fundamentally, splitting needs to identify the region of code dominated by a particular basic block. That construct seems both general and extremely useful. I think we should have some generic infrastructure for computing it and using it, and RegionInfo seems as nice of an API as any.</div>
<div><br></div><div>Nadav pointed me at a paper describing a linear computation of regions, but I don't have time to implement it at the moment...</div><div><a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.5126">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.5126</a> </div>
</div>