[PATCH] D17555: [Feedback requested] Implement cold spliting

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 24 11:43:13 PST 2016


On Wed, Feb 24, 2016 at 11:34 AM, Pete Cooper <peter_cooper at apple.com>
wrote:

>
> > On Feb 24, 2016, at 11:25 AM, Philip Reames <listmail at philipreames.com>
> wrote:
> >
> > reames added a comment.
> >
> > FYI, this is something I'm interested in for the JIT use case.  My code
> has lots of essentially never executed slow paths and getting them pulled
> far away from the normal code is interesting.
>
>
> > Note that my case may be different that others in that the blocks I'm
> interested in pulling away are stone cold/never executed.  This gives a
> clear profitability heuristic which is one of the complex parts of doing
> this for the general case.
> If they are stone cold, are you currently adding branch probabilities to
> the branch leading up to them?  If so, could you add probabilities making
> it always trigger the splitting here?
>
> The reason I ask is that I’ve discussed an idea off list about a stone
> cold attribute we could put on C++ methods which infects dominated code,
> and I was going to get it to propagate unlikely branches (via probability
> info) as high as possible.
>
> For example, lets say clang’s diagnostic error method is considered stone
> cold, because if we take it, then we are eventually going to exit non
> zero.  Given this code
>
> if (some_condition) {
>   // This is normal code (0)
>   if (error_occurs) {
>     // This is now error code (1)
>     Diag.error();
>     // Maybe some more code here (2)
>   }
>   // And maybe here we have some more code (3)
> }
>
> Ideally, at the IR level, we can see the stone_cold attribute on the call,
> and propagate it up and down the dom tree.  So blocks (1) and (2) are made
> stone cold, but (0) and (3) aren’t because they are also reachable via a
> non stone_cold path.
>

yes -- this heuristic is well recognized and is a good candidate to be
implemented in BranchProbabilityInfo.cpp -- similar to propagation of
'noreturn/unreachable' info in the analysis.

David


>
> Would something like that work for you too?
>
> And sorry for being a little off topic on the patch, but I just wanted to
> get this idea out there while it was fresh.
>
> Cheers,
> Pete
> >
> >
> > http://reviews.llvm.org/D17555
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160224/2bf95656/attachment.html>


More information about the llvm-commits mailing list