------- Comment #8 from anton at mips dot complang dot tuwien dot ac dot at
2005-12-09 13:46 -------
Subject: Re: pessimization of goto * ("computed goto")
rguenth at gcc dot gnu dot org wrote:
>
>
>
> ------- Comment #7 from rguenth at gcc dot gnu dot org 2005-12-09 11:51
> -------
> > 2) If you do reorder the blocks, you should not merge indirect
> > branches on CPUs with BTBs, for better branch prediction.
>
> I would rather say that you should not merge frequently executed
> indirect branches.
Yes, that's a refinement.
> There is certainly an upper bound of indirect
> branches after that merging is profitable again,
Yes, once the indirect branch gets evicted from the BTB between two
executions, you might just as well merge it with another indirect
branch of the same kind. While not all rarely executed indirect
branches will have this property (the few executions might occur in a
burst), many of them will, and for the rest the number of executions
and thus the penalty of doing it wrong will be low.
OTOH, the potential speed benefit of this refinement is also low; so
the main benefit is probably in code size.
- anton
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25285
