potential simple loop optimization assistance strategy?

[Devang Patel]

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