[PATCH] D35804: [BPI] Detect branches in loops that make themselves not taken

[John Brawn via llvm-commits]

> The problem I mentioned are in two different directions. In one direction, if MAX/step is really large, the BP computed in this
> analysis won't be biased enough. On the other hand, for very short trip count loops (which can also be very hot), the opposite can
> happen.  To avoid overcomplicate the analysis, I think it is fine to do a very simple 'step' analysis by looking at the phi. MAX is
> already known.

We do know that the value on one side of the comparison is a constant, but we don’t know exactly (without some more work) what kind
of comparison it is or how it relates to the loop iteration, e.g. we could have a down-counting loop where the constant being compared
against is zero, or there’s the test11 in the tests that are added where a value is being flipped and there’s no incrementing happening at
all.

John

From: Xinliang David Li [mailto:davidxl at google.com]
Sent: 20 February 2018 17:05
To: reviews+D35804+public+89d09923a0755f84 at reviews.llvm.org
Cc: John Brawn; serguei.katkov at azul.com; Chandler Carruth; Vedant Kumar; Junbum Lim; Hal Finkel; llvm-commits; wmi; Florian Hahn
Subject: Re: [PATCH] D35804: [BPI] Detect branches in loops that make themselves not taken



On Tue, Feb 20, 2018 at 8:51 AM, John Brawn via Phabricator <reviews at reviews.llvm.org<mailto:reviews at reviews.llvm.org>> wrote:
john.brawn added a comment.

In https://reviews.llvm.org/D35804#1002438, @davidxl wrote:

> The branch probability depends on other factors which is not considered here.
>
> For instance
>
> 1. the value of MAX. In the example, if MAX is 1, then the branch probablity should be 50%
> 2. the step /increment of n
>
>   More generally, the predicted probability should depend on MAX/step. The larger the value, the less likely the branch is taken.


That's true, but making the probability more precise would make the analysis here more complicated and I don't think it's worth it. 50% is a safe lower bound: we know the branch will be not taken at least 50% of the time and never less than that, assuming a large enough number of iterations (for small numbers of iterations whether the iteration count is even/odd will have an effect, e.g. for 1 iteration the branch may be always taken, but when the loop has a small number of iterations it won't be hot so it doesn't matter what we think the probability is).

The problem I mentioned are in two different directions. In one direction, if MAX/step is really large, the BP computed in this analysis won't be biased enough. On the other hand, for very short trip count loops (which can also be very hot), the opposite can happen.  To avoid overcomplicate the analysis, I think it is fine to do a very simple 'step' analysis by looking at the phi. MAX is already known.

David



Repository:
  rL LLVM

https://reviews.llvm.org/D35804



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180221/484af17e/attachment.html>