Helping the optimiser
The success which the optimiser has with your code depends to a large extent on
the code itself. In order to ensure that the object code is correct in all
cases, the optimiser takes a conservative approach which can sometimes mean
that potential optimisations are ignored. As a rule of thumb, the more
structured the code appears to the optimiser, the more optimisations it can
apply. It is difficult to give hard and fast rules as to how best to maximise
the optimisation which can take place, but a number of general points should be
GOTOs can often inhibit optimisation. This is particularly the case in tight
loops. You may be able to achieve the effect you want by using a logical
Function and subroutine calls within loops prevent many optimisations from
occurring. Apart from the fact that no register tracking can take place across
CALL statements and function references (the called routine does not save the
register set), many of the loop optimisations cannot take place.
Even if the CALL statement or function reference appears to be "loop
invariant" in some sense (for example, all of its arguments are themselves
loop invariant), the CALL statement or function reference cannot be moved
because of side effects which the routine may have, or common variables which
it uses which are not loop invariant.
Thus, it is up to you to remove CALLs and function references which are
genuinely loop invariant from out of your loops.