------- 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