This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/25285] pessimization of goto * ("computed goto")
- From: "anton at mips dot complang dot tuwien dot ac dot at" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Dec 2005 13:46:34 -0000
- Subject: [Bug rtl-optimization/25285] pessimization of goto * ("computed goto")
- References: <bug-25285-895@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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