|MIPS optimizing compiler email@example.com (1997-08-28)|
|Re: MIPS optimizing compiler firstname.lastname@example.org (1997-08-30)|
|Re: MIPS optimizing compiler email@example.com (1997-08-30)|
|Re: MIPS optimizing compiler firstname.lastname@example.org.OZ.AU (1997-09-03)|
|Re: MIPS optimizing compiler robert.wilson@Eng.Sun.COM (Bob Wilson) (1997-09-07)|
|Link time optimization (was: MIPS optimizing compiler) email@example.com (1997-09-07)|
|From:||firstname.lastname@example.org.OZ.AU (Fergus Henderson)|
|Date:||3 Sep 1997 00:58:01 -0400|
|Organization:||Comp Sci, University of Melbourne|
email@example.com (SimGraphics) writes:
>Bjorn De Sutter <firstname.lastname@example.org> wrote:
>>I'm starting my research on optimzing linkers. I read in a Ph.D thesis
>>that the highest optimization flag on the MIPS compiler, would enable
>The SGI/MIPS "optimizing linker" is a big failure. Briefly: compiler
>would produce *.u files with intermediate code instead of object code
>*.o; linker would link *.u files, and then run a global code
>generator/optimizer to produce a.out executable. Libraries of *.u
>code could be made in *.b format, similar to *.a for *.o.
One significant problem with this was that in order to use the
optimizing linker, it wasn't just a matter of adding `-O3' to CFLAGS,
you also had to modify your make files. That made it a pain to use.
Even worse, with IRIX 5.x, in order to use `-O3' you had to also
compile with `-non_shared', and compiling with `-non_shared' required
the non-shared versions of the C library to be installed, which was
not the default (or at least was not always the case). You also had
to have non-shared versions of any third-party libraries that you
wanted to link with. If you were using gcc, for example, then you
needed a non-shared version of `libgcc.a' installed, and the gcc
makefile did not install one, so you needed to do install it by hand.
>About 3-4 years ago SGI internaly recognized hopelessness of that
I don't think the idea of this sort of link-time optimization is
hopeless, although the SGI/MIPS implementation may have been
>SGI has been pushing this for a while, till about 1995. It never
>really worked, in the sense that SGI never would ship any of their
>proprietary code in the *.u or *.b format.
>Dynamic shared objects are the game where all the current interest goes.
Agreed. DSOs can significantly improve overall system performance, if
significant sharing takes place at runtime. Link-time optimizations
must be able to coexist with the use of DSOs.
The flaws in the SGI/MIPS implementation mentioned above are all
addressable. Link-time optimization information can be placed in (a
special section of) standard object files, so that existing makefiles
do not need to be modified. There is no need to require the use of a
different code model (ABI) in order to use link-time optimizations.
The use of link-time optimizations need not prevent the use of DSOs.
Given that the SGI/MIPS implementation had the above-mentioned flaws,
I don't think we can conclude much from its lack of acceptance, except
that future work in this area should avoid these flaws.
Fergus Henderson <email@example.com>
PGP: finger firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.