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

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 28 22:16:49 PDT 2015


On Fri, Aug 28, 2015 at 10:13 AM, Philip Reames via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On 08/28/2015 09:54 AM, Kevin B. Smith via llvm-commits wrote:
>
>> kbsmith1 added a comment.
>>
>> In http://reviews.llvm.org/D12341#235210, @kparzysz wrote:
>>
>> In http://reviews.llvm.org/D12341#235179, @kbsmith1 wrote:
>>>
>>> [...]
>>>>
>>>
>>> I don't think we completely understand each other.  The profiling data
>>> that is attached to MD_prof describes the behavior of the program.  You
>>> want to have something that describes the behavior of the hardware.  Those
>>> are two different things.  The former is independent from the specific
>>> properties of the hardware and can be reused when compiling for different
>>> subtargets.  The latter is not.  I'm not opposed to profiling information
>>> tied to specific hardware in principle, but I think those two kinds should
>>> be easily separable.
>>>
>>
>> No, I really do get that this is for describing the behavior of the
>> program, and I am not trying to use this to describe behavior of the HW.
>> All I am saying, is that you cannot simply describe the branch pattern, and
>> expect to derive predictability information from that.  I just think that
>> the HW feedback data can be used as a good approximation for this program
>> behavior information, and that the branch pattern will not be usable for
>> deriving that information.
>>
> A somewhat horrible though occurred to me after reading this thread.
> Given that many code bases are targeted for multiple distinct hardware
> platforms, and deriving predictability of branch on a particular piece of
> hardware from a description the behavior is somewhat of a non-starter, do
> we need to have a mechanism for describing the predictability of a given
> branch on a particular instance of hardware?  A branch that's entirely
> predictable on one compilation target (say modern x86 excluding Atom),
> might be utterly unpredictable to another (say PPC).  Do we need to support
> this either at the source level (Clang builtins), or the compiler itself?


See my comment above about decompression. Basically, the encoder's job is
to make the data almost perfectly random. This property is independent of
any particular branch predictor. If the encoder is doing its job well (and
they do), it is literally impossible to design a branch predictor that does
well on the data; for it to be otherwise would be a constructive proof of a
superior compression algorithm.

-- Sean Silva


>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/5bf35762/attachment.html>


More information about the llvm-commits mailing list