[PATCH] D12341: add llvm.unpredictable intrinsic and lower it to metadata

[Sean Silva via llvm-commits]

On Fri, Aug 28, 2015 at 8:49 AM, Kevin B. Smith via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> kbsmith1 added a comment.
>
> In http://reviews.llvm.org/D12341#235124, @kparzysz wrote:
>
> > In http://reviews.llvm.org/D12341#234593, @kbsmith1 wrote:
> >
> > > I am suggesting that you only have a single number that represents the
> percentage of time that the direction is mispredicted.
> >
> >
> > This is really the original idea if we assume that a change of direction
> causes a misprediction.  The problem with tracking "misprediction" rate is
> that it does depend on the specific hardware.  The implementation of the
> hardware branch prediction may change between subtargets of the same
> target, which is why I proposed tracking the behavior of the branch
> instead.  A subtarget could then use this information to estimate the
> misprediction rate, which may not be as accurate as tracking misprediction
> itself for that subtarget, but it would be portable.
>
>
> The assumption that a change in branch direction causes a misprediction is
> just not a correct assumption.  Further most branch predictors have global
> state such that they are affected by other nearby branches, and also other
> branches that precede them in execution order. Compiler's really cannot
> model this, and thus attempting to discern/compute branch predictability
> from a pattern based on a specific implementation is unlikely to be
> successful.


Absolutely; at this point, trying to do anything fine-grained with concrete
knowledge of branch prediction probabilities is still a research problem
AFAIK. It's premature abstraction to try to generalize what Sanjay is doing
in this patch, which has a clear use case: the user is an oracle telling
the optimizer that the usual assumptions about the effectiveness of branch
prediction should not be made.

-- Sean Silva


> And most branch prediction algorithms are patented or closely guarded
> intellectual property.  Having an implementation of various HW algorithms
> seems unlikely to be coded into LLVM. A boolean serves the immediate need,
> but I think a 0 to 100 integer, with 0 meaning completely predictable and
> 100 meaning completely unpredictable can serve that same purpose, while
> also allowing HW feedback.  In actual practice, I'd expect anything with a
> unpredictability value higher than about 10 would be considered pretty
> unpredictable.  HW branch prediction rates (correct predictions/total
> branches, over all branches in a program) often run in the 95-98% range,
> making any branch with more than 10% unpredictability, less predictable
> than an average branch.
>
>
> http://reviews.llvm.org/D12341
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150828/f3a41538/attachment.html>