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 noted:
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 variable.
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.
It is a good idea to remove all redundant labels (these are automatically indicated by FTN95's compilation diagnostics).