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

[Pete Cooper via llvm-commits]

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

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