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

[Xinliang David Li via llvm-commits]

ok. Can you add a FIXME comment for limitations here? After that we
probably good to go with this.

On Wed, Feb 21, 2018 at 10:09 AM, John Brawn <John.Brawn at arm.com> wrote:

> > 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> 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/a7d88386/attachment.html>