Re: deadcode optimization

Marco van de Voort <marcov@stack.nl>
4 Apr 2001 00:21:08 -0400

          From comp.compilers

Related articles
[10 earlier articles]
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-03-10)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-10)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-12)
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-03-14)
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-03-14)
Re: deadcode optimization broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-03-22)
Re: deadcode optimization marcov@stack.nl (Marco van de Voort) (2001-04-04)
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-04-10)
Re: deadcode optimization marcov@toad.stack.nl (2001-04-12)
| List of all articles for this month |

From: Marco van de Voort <marcov@stack.nl>
Newsgroups: comp.compilers
Date: 4 Apr 2001 00:21:08 -0400
Organization: Eindhoven University of Technology, The Netherlands
References: 01-03-012 01-03-022 01-03-034 01-03-060 01-03-075 01-03-091 01-03-099
Keywords: optimize, linker
Posted-Date: 04 Apr 2001 00:21:08 EDT

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)


Post a followup to this message

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