Re: link-optimization in C

S. Bochkarev wrote in message 99-05-091...
>Does somebody know: where it is possible to find the correct
>description of linker- operations in the last versions of C ++ from
>Microsoft and Inprise ?


For Microsoft, see e.g.
http://msdn.microsoft.com/library/devprods/vs6/vc++/vccore/_core_.2f.opt.htm
; (registration may be required).


>Practically, the question can be reformulated so:
>
>a) Is there a format of x86-obj-files, where
> local references to a code-segment are
> especially presented ?


Yes. In the Microsoft 32-bit PE file format, which is COFF based, it is
possible to emit a COMDAT section for each function, member function, etc.
By default, any instantiated inline functions and inline member functions
are emitted one per COMDAT. If you compile "cl /Gy" (IIRC) then every
function goes into a separate COMDAT.


>b) If it is:
> - which C/C++ compiler can generate them ?
> - which linker can work with them ?
>c) Which from C-compilers can effectively delete the
> local unused procedures (without conflicts with ANSI-
> definitions of the preprocessor) ?


Microsoft C/C++ can generate them, and the MS Incremental Linker can consume
them and eliminate unused functions, member functions, compiler generated
special member functions, unreferenced data, etc. Local, or
cross-compiland.


I don't understand the parenthetical comment about the preprocessor.


>[I've seen linkers that garbage collect unused procedures, but not on
>Windows systems. I suppose a compiler could put the code for each routine
>into a separate COFF section, then the linker could try to figure out what
>references what, but it'd be a mess. There is a provision for deleting
>duplicate expanded templates and the like, but that depends on all of the
>duplicates having an identical mangled name and deleting all but one
>of the identically named sections. -John]


That's not correct. First, it's not a mess -- it works very well, and it is
now almost a requirement for a competitive C++ development tools product.


Yes, the linker can eliminate redundant (present in multiple object modules)
copies of instantiated inline member functions, compiler generated special
member functions, template function expansions, vtables, etc. WITH THE SAME
NAME.


BUT it can also eliminate code-identical template function expansions WITH
DIFFERENT NAMES. That is, if Ptr<X>::operator*() and Ptr<Y>::operator*()
expand to the same bits, and (I assume) same relocs, the linker (link /opt
or link /icf ("identical comdat folding")) can fold them together into one
copy with both names. And it can do multiple passes to catch transitively
identical template expansions and so forth.


See the above MSDN URL for more information.


Jan Gray
[Thanks, just in time to fix some lies in the manuscript for the linker
book. -John]

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