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

Sat Aug 29 11:28:15 PDT 2015

----- Original Message -----

> From: "Sean Silva" <chisophugis at gmail.com>
> To: "Kevin B Smith" <kevin.b.smith at intel.com>
> Cc: reviews+D12341+public+5f663c68720e9677 at reviews.llvm.org, "Sanjay
> Patel" <spatel at rotateright.com>, "Chandler Carruth"
> <chandlerc at gmail.com>, "Krzysztof Parzyszek"
> <kparzysz at codeaurora.org>, "Hal Finkel" <hfinkel at anl.gov>, "Bob
> Wilson" <bob.wilson at apple.com>, kubastaszak at gmail.com,
> "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Saturday, August 29, 2015 12:11:18 AM
> Subject: Re: [PATCH] D12341: add llvm.unpredictable intrinsic and
> lower it to metadata

> On Fri, Aug 28, 2015 at 8:16 AM, Smith, Kevin B <
> kevin.b.smith at intel.com > wrote:

> > From: Sean Silva [mailto: chisophugis at gmail.com ]
> 
> > Sent: Thursday, August 27, 2015 5:39 PM
> 
> > To: reviews+D12341+public+5f663c68720e9677 at reviews.llvm.org ;
> > Smith,
> > Kevin B
> 
> > Cc: Sanjay Patel; Chandler Carruth; Krzysztof Parzyszek; Hal
> > Finkel;
> > Bob Wilson; kubastaszak at gmail.com ; llvm-commits
> 
> > Subject: Re: [PATCH] D12341: add llvm.unpredictable intrinsic and
> > lower it to metadata
> 

> > On Thu, Aug 27, 2015 at 3:13 PM, Kevin B. Smith via llvm-commits <
> > llvm-commits at lists.llvm.org > wrote:
> 
> > kbsmith1 added a comment.
> 

> > No, I am not suggesting you have more history. I am suggesting that
> > you only have a single number that represents the percentage of
> > time
> > that the direction is mispredicted. It would make a lot of sense
> > for
> > it to be a simple 0-100 value, and would represent the percentage
> > of
> > mispredictions. Anything else takes more space, and is much too
> > closely tied to the branch predictor.
> 

> > I have seen 2 independent bug reports recently where the simple
> > annotation to the compiler "assume that this is completely
> > unpredictable" would have been the solution. Some pieces of code
> > very closely approximate this, especially in decompression
> > algorithms where by definition if the encoder is doing its job then
> > the pattern cannot be guessed. Other data-driven branches can
> > approximate this behavior as well.
> 

> > This is more a declaration about the actual pattern of the branch.
> > A
> > number indicating the percentage of mispredictions (or any
> > empirically collected number) is not a generalization of this
> > annotation.
> 

> > -- Sean Silva
> 

> > Sean – Yes, I agree this is about an inherent property of the
> > branch,
> > or condition. But percentage of mispredictions could easily be used
> 
> > to convey that information. Simply set the value to 100 to say that
> > 100% of the time the branch/condition is mispredicted, and consider
> > that
> 
> > the declaration about the actual pattern, rather than an actual
> > number.
> 
> I think this is a perfect example of why using such a percentage
> needs more thought (especially which kinds of optimizations we would
> hope to do based on the number).
I agree that we should not prematurely generalize. As I recall, I had asked whether it would make sense to use the same setup for this as we use for the branch-probability metadata. It seems the answer is a resounding no, and we understand why. I think the answer to your question is actually straightforward: A target hook would need to interpret that percentage and make some determination regarding whether the branch was unpredictable enough to treat in the non-default way. That having been said, I agree we should not add facilities with no users, and we can decide on the exact format once we have a user (profiling capability, etc.) that can provide such measurements. 

-Hal 

> Think for a second about what it means for a branch to be 100%
> mispredicted. If I give you a 10 question T/F test with questions
> that you have no clue about, is it harder to get 10/10 or 0/10?
> (trick question).

> Sanjay's patch is motivated by a specific use case (that has arisen
> in practice multiple times for us) where the user would like to
> inform the compiler that the branch should not be expected to be
> predictable in any way.

> -- Sean Silva

> > To some extent this mimics __builtin_expect, which allows a
> > specification of the probability of a condition having a certain
> > value, but where in actual usage, the user’s usage is likely to be
> > always 0 or always 100 for hinting purposes.
> 

> > This allows a single type of annotation to be used for both the
> > user
> > specified property, and also for HW feedback.
> 

> > Kevin Smith
> 

> > > ABAB can be perfectly predicted often, AABB can be perfectly
> > > predicted often. The number of transitions from true to false or
> > > vice-versa has a poor
> > 
> 
> > > correlation to branch predictability, just as the branch
> > > probability
> > > has a poor correlation to branch predictability.
> > 
> 

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

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150829/b6fd7e0d/attachment.html>