spatel added a comment.
[reposting this as a general comment because the inline comment did not seem to
make it to the mailing list]
Yes, I want to merge the handling of builtin_expect and builtin_unpredictable.
Currently, the 'unpredictable' metadata has no parameters; it is an empty
string like:
br i1 %or.cond, label %bb3, label %bb4, !unpredictable !2
...
!2 = !{}
In http://reviews.llvm.org/D12341, we considered having an integer parameter
value that would be a measure of the unpredictability. For example, this could
be used with PGO if someone had collected branch mispredict data as part of a
profiling run.
So as a first proposal, let's say we add an integer parameter for
predictability for this metadata type. We could define '-1' to mean 'perfectly
predictable' and so builtin_expect would map to this:
!2 = !{-1 42} <--- perfectly predictable with expected value of '42'
Rereading your question, I'm now wondering if you are asking if we can get rid
of the source level builtin_unpredictable() ? I had not considered that, but I
think that is also possible if we add a flag to builtin_expect() to mean 'this
branch is unpredictable'.
Please let me know if I answered the correct question. :)
So, yes this patch is transitional - hopefully, no more than a few days. I'm
going to audit where we actually use profile data to make transform decisions.
Once those places (I'm assuming they actually exist!) are updated to look at
the unpredictable metadata, we can fix up this clang code to match the
optimizer's algorithms.
http://reviews.llvm.org/D19299
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
