Re: deadcode optimization

> If you do that, then you won't get optimal dead code elimination.
> Obviously you won't eliminate unused global data, but furthermore if
> the initializers for that data contain function pointers, they can
> drag in other unused code.


We never intended to eliminate unused global data, and did not
implement as such. Yes, therefore a global unused "function pointer"
will drag in some unused code. The gain was not worth the expense of
link time increases in time. An for most apps there was no likelihood
of any gain. I know Borland Pascal did smart link data via their TPU
format.


However we did implement smart linking of "virtual methods" in object
oriented languages (we have implemented a couple). Here there was a
real gain to be had. Since method tables of compilers always have
something linked in, and the data is never unused, we had the linker
replace unused method fixups with a another method, therefore linking
in a different method than the one the compiler setup. This other
method was a failsafe in case the method was somehow called. This
could not happen in our system, but who knows what tools (other
compilers/assemblers) someone was using, and if they did something in
a unorthodox manner. In that case they would get an error message and
would know not to use that linker option, or access code via industry
"standards".


We added the above feature way back in the 16-bit real mode DOS days
in our Borland Pascal compatible compiler. It made a huge difference
in code that used the popular object oriented user interface
libraries.


I don't much care about abstract "total" dead code elimination. I care
about what users are doing in the real world. What one or two users
are doing is not of much concern.


--
Norman Black
Stony Brook Software


> >> This is not so easy: what about static variables ? You can rename
> >> them, but you will break debugger compatibility...

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