|[5 earlier articles]|
|Re: Dead code elimination email@example.com (1991-11-05)|
|Re: Dead code elimination firstname.lastname@example.org (1991-11-06)|
|Re: Dead Code Elimination email@example.com (1991-11-07)|
|dead code elimination firstname.lastname@example.org (1991-11-26)|
|Re: Optimizing Across && And || email@example.com (1995-02-23)|
|Re: Optimizing Across && And || firstname.lastname@example.org (1995-03-15)|
|dead code elimination email@example.com (1995-03-23)|
|From:||firstname.lastname@example.org (Preston Briggs)|
|Date:||Thu, 23 Mar 1995 22:59:10 GMT|
>[about dead code elimination]
>there is another side to dead code
>detection, namely *notification*. It is true that properly written programs
>shouldn't contain dead code. Therefore, presence of dead code indicates
>a possible problem.
Dead code arises in many properly written programs. It can happen in
C programs as a result of macro expansion. It can happen as a result
of inline expansion, especially of library routines. And it happens
all the time as a result of optimization (strength reduction, value
It's hard to imagine being able to give useful warning messages for
all these cases; but perhaps some special situations deserve
attention. For example, the ability of a good dead code eliminator to
remove useless loops is nice for benchmarking, but we find it helpful
to warn people when we zap their loops.
In one case, a programmer wrote some mutually recursive routines, but
didn't get the base case correct (that is, he wrote an obscure
infinite loop). The compiler did some inlining, turned the recursion
into a loop, then noticed that nothing in the loop was ever used
(since the loop never terminated), and eliminated the entire loop. It
also warned the programmer, who was quite surpised since the source
code didn't have any loops...
Return to the
Search the comp.compilers archives again.