Re: deadcode optimization

Hans-Bernhard Broeker wrote:


> Norman Black <stonybrk@ix.netcom.com> wrote:
> [...]
> > I understand the legacy of C compilers back to the original. They have
> > global and local symbols in the object format. A static in a file
> > would use a local symbol. As a non C user I could care less about that
> > and have no use for it. The languages I use all support compilation
> > units and the C "symbol issues"(namespace stuff) disappear with the
> > existence of compilation units. Even so I still do not see the need,
> > other than legacy, to use local symbols in a C compiler.
>
> I think you may have overlooked one central point, here. First of all,
> C does support compilation units. Syntactic details vary wildly
> between C and the somewhat stricter languages , but the concept is
> there.
>
> But talking about dead code elimination, previous articles in this
> thread had pointed out that the compilation units have to be *broken
> apart* before they are presented to a usual Unix-type linker. And in
> this cracking-open process it is that variables local to the
> compilation unit will cause problems, since the compilation unit is no
> longer the same as the linkage unit.
>
> This problem is, AFAICS, completely independent of whether you call
> these variables 'static', in C parlance, or define them in the
> 'implementation part' of a more strongly modularized language. It's
> rather caused by the concept of an monolithic compilation unit
> (i.e. an 'object file) being presented to a linker that has no way of
> isolating individual functions or data objects from such a monolithic
> unit.
>
> I.e. it's the linker that makes this hard, not the compiler, nor the
> language it compiles.


For deadcode removal, the linker is indeed the problem. One can solve this
by creating an object file per symbol. This is horribly slow. The
slowlyness can be reduced a magnitude of 2 by elimintating the backend
assembler and directly pooping out .a's with all objects


If you want an example for this, check the Free Pascal compiler
(www.freepascal.org)

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