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

[Sean Silva via llvm-commits]

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). 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150828/ddec4150/attachment.html>