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

[hfinkel@anl.gov via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D12341#234400, @kparzysz wrote:

> In http://reviews.llvm.org/D12341#234320, @hfinkel wrote:
>
> > My understanding is that the way that llvm.expect was implemented is considered to be a mistake that we're now stuck with for backwards-compatibility reasons
>
>
> One downside of using metadata is that it makes it harder to edit IR by hand.  Debugging or aliasing information is pretty much static, but branch prediction information could be manipulated by hand for experiments.  I don't know how important that is though.


The problem with the intrinsic is that it is an optimization hint that needs to be removed/transformed before the code can be optimized. That's not very useful. Plus, it confuses information about a value with information about a branch based on that value.

To your point: The proposed metadata is pretty simple, but I agree that metadata can be a pain to manipulate by hand because you often need to renumber things. I'd not be opposed to some IR syntax enhancement that made it easier to write by hand. That's a separate matter, however.

> I still think we would want a distinct metadata type for 'unpredictable' rather than using 'prof' metadata because there are no special values of prof data that could be used to indicate unpredictability. Ie, just because both sides of a branch have the same weight, does not necessarily make them unpredictable.


I agree that branch probabilities and unpredictability are separate concepts. It is easy to arrange for a 50/50% branch to be almost perfectly predictable  (just have longs runs of each possibility). In the long run, we might want this not to be a Boolean setting (it does not seem far fetched to me to set metadata like this based on branch-prediction miss rates based on actual profiling data), but I'm okay with starting with this for now. That having been said, it might be worthwhile, conceptually, to simply mirror the existing profiling data so that we can share the relevant code. Meaning that we have metadata, that instead of counting the number of relative branches, counts the relative number of mispredicated branches (or predicted branches). Thoughts?


http://reviews.llvm.org/D12341