it might worth extend __builtin_expect to take more parameters:
1) argument to specify actual probability: __builtin_expect (x, 10, 0.6)
2) a more general way of doing this is to allow specifying multiple
values, and the probability is determined by # of occurances:
__builtin_expect (x, 10, 10, 20) --> tells compiler x is expected to
be 10 66% of the time, and 33% of time with value twenty.
3) a special value can be reserved to indicate if the branch is
predictable or not.

David

On Thu, Sep 26, 2013 at 3:27 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> Hi,
>>
>> Current default probably for builtin_expect is 0.9996.
>> This makes the freq of unlikely bb very low (4), which
>> suppresses the inlining of any calls within those bb.
>>
>> We used FDO data to measure the branch probably for
>> the branch annotated with builtin_expert.
>>                                                          For google
>> internal benchmarks, the weight average
>> (the profile count value as the weight) is 0.9081.
>>
>> Linux kernel is another program that is heavily annotated
>> with builtin-expert. We measured its weight average as 0.8717,
>>                                               using google search as
>> the workload.
>
> This is interesting.  I was always unsure if programmers use builtin_expect
> more often to mark an impossible paths (as those leading to crash) or just
> unlikely paths.  Your data seems to suggest the second.
>
> We probably also ought to get analyze_brprob working again. It was always
> useful to get such a data.
>>
>>
>>     This patch sets the alternate hirate probability for
>> builtin_expert
>> to 90%. With the alternate hirate, we measured performance
>>                                               improvement for google
>> benchmarks and Linux kernel.
>>
>>
>>                               -Rong
>> 2013-09-26  Rong Xu  <x...@google.com>
>>
>>       * params.def (DEFPARAM): New.
>>       * params.def: New.
>>       * predict.c (tree_predict_by_opcode): Alternate
>>         probablity hirate for builtin_expect.
>
> This also seems resonable for mainline.  Please add a comment
> to the parameter explaining how the value was determined.
> Please also add invoke.texi documentation.
>
> For patches that seems resonable for mainline in FDO/IPA area,
> i would apprechiate if you just added me to CC, so I do not lose
> track of them.
> Honza

Reply via email to