This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: branch predictions
- To: Jason Eckhardt <jle at cygnus dot com>
- Subject: Re: branch predictions
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 04 May 2000 09:06:31 -0600
- cc: gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <Pine.SOL.3.91.1000504065234.13964B-100000@cse.cygnus.com>you writ
e:
> > 3. If we do not have any kind of prediction and one of the blocks
> > physically follows the current block, then predict the block which
> > physically follows the current block. ie, don't rearrange code
> > at random ;-)
> >
>
> I forgot to mentioned that this should be okay. But its not clear whether
> its any better than a random prediction, at least if we believe the
> results in ball/larus' paper (they do a 'random' prediction in this case)
It happens fairly often -- if you look at Ball's paper at table 5, you'll
see that the "default" heuristic is triggered often enough to think about --
it looks like an average would be around 15-25% of all branches would be
covered by the "default" heuristic if all of the other heuristics are
implemented.
While there's no evidence that my heuristic will improve performance, it does
result in less jump rearrangement and code movement. This will help keep us
from un-doing some of the code layout around conditional branches done by
the tree->rtl conversion pass. It will also result in less jump and code
placement disruption which will likely make the resulting code easier to debug
:-)
In many ways it's similar to the tie breaker we use in the scheduler when we
have two equally profitable insns ready to issue -- we keep them in original
order to minimize debugging impact as well as impact on later optimization
passes (cross jumping).
jeff