> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | Paul Schlie <[EMAIL PROTECTED]> writes:
> | 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;
>
> I would not predicate the transformation on that assumption
> (negligible cost of assertion). That could happen in an inner tight
> loop.
>
> What we need is a balance that does not require too much of work from
> the compiler -- because otherwise, it won't happen.
Understood, but can't help but wonder how many nested loops realalisticly
have nested data dependancies; but none the less, I guess all it takes is
one important one to justify worrying about it. And agree it would be nice
if static assertions could be made in some reasonable way embedded in the
code.
