Re: deadcode optimization

tgi@netgem.com (Tristan Gingold) writes:


>Norman Black wrote:
>>"Smart linking" is trivial for a compiler do handle and have ALL
>>linkers in existence support the unused code "removal".
>>
>>All that need be done is have the compiler output library/archive
>>files directly with one procedure per object in the library. Our
>>compilers have done this since 1987 and any linker appropriately does
>>not link in unused code.
>
>This is not so easy: what about static variables ? You can rename them, but
>you will break debugger compatibility...
>
>Tristan.
>[Dead code is dead code; if nothing refers to them, you can safely remove
>them. -John]


I think the situation that Tristan Gingold is referring to is the following:


/* source file 1 */
static int foo;
int bar_1() { return ++foo; }
int bar_2() { return --foo; }


/* source file 2 */
static int foo;
int baz_1() { return ++foo; }
int baz_2() { return --foo; }


/* source file 3 */
extern int baz_1();
extern int baz_2();
int main() {
return baz_1() + baz_2() + bar_1();
}


Here the program contains two different variables named `foo', and
neither of them are dead.


If you put each function in its own object file, then you need to give
those static variables extern linkage (so that e.g. `bar_1()' and
`bar_2()' both access the same `foo') and different names (so that
e.g. bar_1() and baz_1() access different `foo's).


A similar issue arises for function-local statics:


int bar() {
static int foo;
return ++foo;
}


int baz() {
static int foo;
return ++foo;
}


Depending on whether the assembler and/or the object file format
support scopes and local statics, you may need to rename local statics
to ensure that their names are unique.


Of course, whether or not this problem will arise depends on your source
language, and on whether you have control of the debugger. For Mercury,
for example, there's three reasons why this problem doesn't come up:
(a) symbols are always module-qualified,
(b) the language doesn't global/static variables anyway, and
(c) even if it did, we have our own debugger, so we can freely
modify the debug info format.
(a) and/or (b) apply to many modern languages, and (c) will often apply.


Even if they don't, you may be willing to just live with imperfect debugger
support -- the user will still be able to access the variables in the
debugger, they'll just need to use the mangled names, and after all it only
occurs when this particular optimization is enabled, and as explained earlier
you probably don't want to make that the default.


But if you're implementing a sufficiently C-like language, and you
want to use the platform's existing debuggers, and you want high-quality
debugger support, then you may need to deal with this issue.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
[I've always wondered why linkers never offer more than one level of
local/global name space. -John]

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