On Jul 1, 2005, at 8:51 AM, Paul Schlie wrote:
As in general it seems that as the compiler knows what it needs to
know to
enable ideal loop optimization, why not simply have it assert: if
it knew x,
then it could do y? For example, if given something like:
for (i = x; i < y; i++){ ... }
Where it may not be known statically if x < y, or what (y - x) % N
may be;
therefore possibly difficult to ideally optimize. Where then
instead of
assuming something that may not be factual by default, it could
generate a
warning indicating that the loop may be further optimized if it
knew that
x < y, and/or (y - x) % N == 0. Where then the programmer could
then choose
to warrant it by preconditioning the loop:
assert((x < y) && ((y - x) % 4)); // which could throw an exception.
for ((i = x; i < y; i++){ ... }
Where although it would require run-time code, it's overhead should be
insignificant if the benefit of the optimization were truly
significant;
thereby enabling the programmer to help the compiler help himself,
without
the introducing potentially arbitrary behaviors, by explicitly
trapping them
instead.
Where if the programmer didn't add an assertion, or explicitly
enable a
potentially unsafe optimization, then the compiler should not presume
anything other than what it truly factually knows, which may include
optimizations based on whether the target traps or wraps overflow,
etc.
(it may even be reasonable for the compiler to optionally insert
run-time
assertions automatically to enable the deterministic trapping of
conditions
which may be inconsistent with the optimizations assumptions?)
Various compilers support #pragma to inform compiler about approx.
number
of loop iterations.
-
Devang
