This is the mail archive of the
mailing list for the GCC project.
Re: [google gcc-4_8] alternate hirate for builtin_expert
- From: Rong Xu <xur at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Fri, 27 Sep 2013 13:42:34 -0700
- Subject: Re: [google gcc-4_8] alternate hirate for builtin_expert
- Authentication-results: sourceware.org; auth=none
- References: <CAF1bQ=RnCQGRrdUxV0Mpj9wAiB=fUy+fzouGOf0Rj_YWt2TMoA at mail dot gmail dot com> <20130926222744 dot GC21484 at kam dot mff dot cuni dot cz>
On Thu, Sep 26, 2013 at 3:27 PM, Jan Hubicka <firstname.lastname@example.org> wrote:
>> 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.
I don't find an official guideline on how this should be used. Maybe
in gcc user-guide helps.
> 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
>> to 90%. With the alternate hirate, we measured performance
>> improvement for google
>> benchmarks and Linux kernel.
>> 2013-09-26 Rong Xu <email@example.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.