|Linkers - making executables smaller email@example.com (1998-06-18)|
|Re: Linkers - making executables smaller firstname.lastname@example.org (Jerry Leichter) (1998-06-19)|
|Re: Linkers - making executables smaller email@example.com (1998-06-19)|
|Re: Linkers - making executables smaller firstname.lastname@example.org (1998-06-19)|
|Re: Linkers - making executables smaller corbett@lupa.Eng.Sun.COM (1998-06-24)|
|Re: Linkers - making executables smaller email@example.com (1998-06-24)|
|Re: Linkers - making executables smaller firstname.lastname@example.org (1998-06-24)|
|From:||email@example.com (Bill Leonard)|
|Date:||19 Jun 1998 23:30:02 -0400|
|Organization:||Concurrent Computer Corporation, Ft. Lauderdale FL|
firstname.lastname@example.org (Peter Hall) writes:
> Have you come across any technologies in which the
> linker performs 'global' optimisations?
Many modern compilers, especially for C++ and Ada, perform global
optimization and program analysis steps at the link stage. The
Concurrent compilers do this, for example.
Often these optimization/analysis steps are not really performed by
the linker itself, but rather by a "pre-linker". It still has access
to the same information, and logically one could consider it to be
part of the linker, but it is usually a separate program. This is
done primarily for simplicity (a program should perform one logical
function, not several) as well as to maintain compatibility with other
processors that may use the linker.
> I know that there are profiling tools but these seem to feed back into
> the compiler.
The Concurrent HAPSE Ada compiler does some removal of unused
subprograms just prior to linking. Except in rare instances, I don't
think it is a big win, but it does help to keep the executable size
Most of the optimizations done at link time are generally aimed at
speed, not space. That's probably because speed is of more concern to
more users than space. If any language systems do space optimizations
at link time, it would probably be those that are particularly
targeted towards embedded systems that must meet stringent size
Chances are, though, that the programmer can make a much bigger impact
on size by reorganizing the code than any link-time optimizer can do.
For instance, a pre-linker might be able to remove unused subprograms,
but so probably can the programmer with a little work, and in the
process might gain other advantages as well.
> Is this an unreasonable request? Is there any real reason why linkers
> are stuck in the early 1970s?
I would disagree with this conclusion. Linkers haven't actually
changed much in the last 20 years because, fundamentally, the tasks
they need to perform have not changed. A linker's primary task is to
resolve symbol references among separate object modules. If you want
to perform other tasks, they should be done in separate programs,
perhaps executed as part of the "linking stage" but physically
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Return to the
Search the comp.compilers archives again.