Re: Asserts & optimisation (repost from com.lang.c++)

Just a few thoughts:


> for (int n = 0;n < a.length();++n)
> {
> ++a[n];
> }


Here a ForEach statement would be sufficient to suppress any index
checks. The compiler should know how to translate such a loop, without
using iterators or other objects, that usually are associated with
iterations.


>An intelligent compiler could recognise that in this particular loop,
>the assert condition is always false, and so the check is not
>necessary at run time.


That's subject to how deep the assertions are hidden in the operators and
functions, which are called in the loop.


>Has anyone ever seen an optimising compiler that actually does
>this ?


Not really, but I'm not a compiler expert ;-)


>This would require:
>
>- data flow analysis across function boundaries
>- some way of preventing execution of the "assert" code:
> - multiple entry points to functions with preconditions ?
> - multiple versions of functions, with and without checks ?
> (similar to the code generation done by templates)
> (but avoid having 2^N versions of a function with N asserts !)


When all related functions are declared as inline, or are otherwise expanded
inline, then the dead code can be eliminated by local optimization. Such
behaviour would bypass all your requirements.


>- possibly embedding this information in object modules / libraries
> so separate compilation is handled, too


This could be achieved by something like precompiled headers, which contain the
macro definitions or the inline code. IMO it's common practice to have (source
or compiled) libraries with both code and descriptions together, only C/C++
favours a separation into code modules and unrelated header files.


>This applies to "optimising out" any block of code the compiler
>knows will never be entered, not just asserts like this one.


"assert" typically is implemented as a macro, so that the compiler will only
see sequential code after preprocessing. Some (future) compiler might break all
user-defined subroutines into smaller pieces, which then can be arranged
sequentially and modified as required. The bigger and really often used pieces,
with the same preconditions, then can be implemented as subroutines, where the
compiler can use well known optimization procedures for finding the "cheapest"
solution.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.