[llvm-commits] PATCH: Add a function splitting pass to LLVM which extracts cold regions into their own functions

[Chandler Carruth]

On Mon, May 14, 2012 at 11:23 AM, Andrew Trick <atrick at apple.com> wrote:

>
> On May 5, 2012, at 12:54 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> > 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).
> >
> > 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.
> >
> > 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.
>
> Chandler,
>
> Very nice.
>
> 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?
>

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).

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.

Nadav pointed me at a paper describing a linear computation of regions, but
I don't have time to implement it at the moment...
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.5126
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120514/7d6c5fd7/attachment.html>