Re: Update LTO plugin interface

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor <iant@google.com> wrote:
> > "H.J. Lu" <hjl.tools@gmail.com> writes:
> >
> >> ? ? ? b. Compiler plugin controls what linker uses to generate the final executable:
> >> ? ? ? ? ? ? ? i. The linker command line order should be the same, with or without LTO.
> >> ? ? ? c. Add a cmdline bit field to
> >> ? ? ? struct ld_plugin_input_file
> >> ? ? ? {
> >> ? ? ? ? ?const char *name;
> >> ? ? ? ? ?int fd;
> >> ? ? ? ? ?off_t offset;
> >> ? ? ? ? ?off_t filesize;
> >> ? ? ? ? ?void *handle;
> >> ? ? ? ? ?unsigned int cmdline : 1;
> >> ? ? ? };
> >
> > Just make it an int. ?But I don't see why this is needed. ?The plugin
> > already knows the files that it passed to add_input_file and
> > add_input_library. ?Why does it need to linker to report back where the
> > file came from? ?Why doesn't the plugin just keep track?
> >
> 
> It is used to keep the same linker command line order. With LTO,
> linker should use
> 
> crtX.o *trans*.o -lbar -lgcc -lc ... crtX.o
> 
> instead of
> 
> crtX.o -lbar -lgcc -lc ... crtX.o  *trans*.o
> 
> to generate final executable.  2 orders may generate different
> executables.

Hmm and when I have something like

ctrX.o non-lto1.o lto1.o non-lto2.o lto2.o .... crtX.o
and then linker plugin produce ltrans0.o combining both lto1.o and lto2.o, ho
we will deal with non-lto2.o?

If we get into extending linker plugin interface, it would be great if we would
do somehting about COMDAT.  We now have RESOLVED and RESOLVED_IRONLY, while the
problem is that all non-hidden COMDAT symbols get RESOLVED that pretty much
fixes them in the output library.

I would propose adding RESOLVED_IRDYNAMIC for cases where symbol was resolved
IRONLY except that it is externally visible to dynamic linker.  We can then allow
compiler to optimize this symbol out (same way as IRONLY) if it knows it may or
may not be exported - i.e. from COMDAT flag or via -fwhole-program.

Honza
> 
> -- 
> H.J.