This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: optimizing predictable branches on x86
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Nick Piggin <nickpiggin at yahoo dot com dot au>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 26 Feb 2008 11:14:42 +0100
- Subject: Re: optimizing predictable branches on x86
- References: <200802261434.12032.nickpiggin@yahoo.com.au>
Hi,
> Core2 follows a similar pattern, although it's not seeing any
> slowdown in the "no deps, predictable, jmp" case like K8 does.
>
> Any comments? (please cc me) Should gcc be using conditional jumps
> more often eg. in the case of __builtin_expect())?
The problem is that in general GCC's branch prediction algorithms are
very poor on predicting predictability of branch: they are pretty good
on guessing outcome but that is.
Only cases we do so quite reliably IMO are:
1) loop branches that are not interesting for cmov conversion
2) branches leading to noreturn calls, also not interesting
3) builtin_expect mentioned.
4) when profile feedback is around to some degree (ie we know when the
branch is very likely or very unlikely. We don't simulate what
hardware will do on it).
I guess we can implement the machinery for 3 and 4 (in fact once
I played adding EDGE_PREDICTABLE_P predicate that basically tested if
the esimated probability of branch is <5% or >95%) but never got really
noticeable improvements out of it and gave up.
It was before Core2 times, so it might be helping now. But it needs
updating for backend cost interface as ifcvt is bit inflexible in this.
I had BRANCH_COST and PREDICTABLE_BRANCH_COST macros.
Honza