🚀 go-pugleaf

From article <8960010@hpfcso.HP.COM>, by mjs@hpfcso.HP.COM (Marc Sabatella):
> [...]                             and if you've written a routine which takes
> a parameter 'n' that gives the iteration count for the loop, no amount of
> static data flow analysis (even interprocedural, in many cases) is going to
> tell you the dynamics of that loop.

Agreed.  So, in lieu of complete information, you optimize the code as
if 'n' were large.  If 'n' really _is_ large, you have a winning solution.
If 'n' is not large, you don't suffer much - the code isn't executed much
in this case.  Of course, the more that is known about 'n' the better
you can optimize the loop.  If 'n' is known to be small, you might 
_completely_ unroll the loop or perform some other modification.  But,
a better hint to the compiler in this case is _not_ to use 'register'
attributes.  Instead, the language sould provide some mechanism for
making (checkable) assertions.  For example:

      Assert(n>0 and n<=15)

The generated code can then test the assertion at run-time and the
compiler can generate the rest of the code efficiently based on the
assertion.  Of course, you might want a compiler option to turn off
the run-time checking of assertions.  Furthermore, this is _much_
more refined and clean than the methods recommended by Peter Grandi
for documenting the assumptions of the programmer.

Every time a language standard comes up for review, some recommendation
like the above 'Assert' feature is brought up (it happened for both C
and Fortran in the last few years).  I don't know what arguments have
resulted in leaving such features out.  The state-of-the-art of
compilers is gradually reaching the point where such assertions
can be used very well indeed.  Oh well....

> [...]                                Now say you have another loop, with a
> fixed count of "10".  Which should the optimizer think is going to be more
> heavily executed?

I don't see your point.  If the loops are disjoint, the registers used by
the first are free by the start of the second.  If the loops are nested,
the inner-most loop should be optimized regardless of any 'register'
declarations.  Since these are the only two possibilities, I don't see
how the lack of information about 'n' can negatively effect the loop
with constant trip-count at all.

J. Giles