A little warning in GMP.h

[Brian Hurt]

On 27 Sep 2004, Torbjorn Granlund wrote:

> Brian Hurt <bhurt at spnz.org> writes:
> 
>   Another comment I'll make is that the cost of a branch is a function of 
>   how predictable it is.  A correctly predicted branch is very cheap- a 
>   clock cycle or two at worst.  It's a mispredicted branch which is 
>   expensive.
>   
> Yes, but eliminating even a very predictable branch has the
> advantage of expanding basic blocks, and thereby facilitate
> scheduling and other optimizations.

Does that actually help?  Note that the compilers that are most likely to
be doing agressive scheduling are also the ones most likely to be
eliminating the branch anyways.  You're arguing that we shouldn't depend
upon one compiler optimization because it might allow the compiler to do
other optimizations.

More specifically, I don't think it helps in this specific case.  We're
calculating a return value, which means we're at the end of a basic block
anyways.  So we're not preventing the blocks before and after the branch
from merging, as there is no block after the branch.  And as a block, the
code (both branch-removed and branching versions) simply isn't that
complicated, and doesn't provide a lot of opportunity for scheduling.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian