This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: branch predictions


  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]