[PATCH] D24118: [JumpThreading] Only write back branch-weight MDs for blocks that originally had PGO info

[Duncan Exon Smith via llvm-commits]

> On Sep 1, 2016, at 18:23, Adam Nemet <anemet at apple.com> wrote:
> 
> anemet added a comment.
> 
> In https://reviews.llvm.org/D24118#532156, @davidxl wrote:
> 
>> There is a fundamental problem in BFI that it can not handle 0 weight -- to workaround it
>> 
>> 1. FE PGO annotator will always add 1 to weights of both targets unconditionally when annotating the branch
>> 2. BFI always add 1 to the weight if it is zero.
>> 
>>  The end result is that
>> 3. we will never see code region annoated with zero frequency/count
> 
> 
> Ah, that totally explains what's happening here.  Is there a PR?
> 
>> 2. for FE PGO, all loop trip count appears to be half of the real trip count.
> 
> 
> Wow, this was going to be next thing for me to investigate, thanks for the insights!

This is not true though.  For FE PGO, the loop trip count is only halved for loops that are covered once. 

If a loop has good coverage, the trip count is barely adjusted.  The adjustment has to do with confidence. 

I'm not sure "adding 1" is the best heuristic, but I'm fairly convinced that "adding 0" is worse.  I believe Jakob linked to a source for his choice of +1 if you want to read up on it (look in the comments in CFE).  

Separately from adjusting heuristics, perhaps loops with statically known trip counts should be given special treatment.  Why rely on statistical heuristics if SCEV knows a loop counts to 10?  IIRC, loops with no coverage are using a fixed heuristic (see BPI) for loop trip counts, something like "10x".  We could have a pass that rewrote branch weights based on SCEV results instead (or use SCEV in BPI). 

> 
> https://reviews.llvm.org/D24118
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160902/af2e9d0e/attachment.html>