Re: [PATCH,trunk+2.20] Fix issues in ld.bfd plugin interface [0/6]

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 26/02/2011 02:14, H.J. Lu wrote:

> 
> The question is if LTO linker should link in non-LTO copy of the same function
> and ignore the LTO-IR copy:

  Well, I think the linker should link at least one of them in, preferably the
IR one if it can so that it can be optimised along with the rest of the
program, but if for some reason the linker can't see that it's needed until
after ltrans, then it has no choice but to link the non-LTO copy, and settle
for what should after all only be a missed optimisation rather than
correctness problem.

> [hjl@gnu-6 pr12496-2]$ make
> as --32  -o start.o start.s
> /usr/gcc-4.6/bin/gcc -m32 -B./ -flto   -c -o main.o main.c
> /usr/gcc-4.6/bin/gcc -m32 -B./ -flto   -c -o div.o div.c
> ar rv libdiv.a div.o
> ar: creating libdiv.a
> a - div.o
> /usr/gcc-4.6/bin/gcc -m32 -B./ -O2 -flto -nostdlib -o prog
> -Wl,--start-group start.o main.o libdiv.a -Wl,--end-group

  When I tried this with ld.hjl on i686-pc-cygwin, I got an undefined
reference to __udivdi3, is that supposed to happen?

> Here div.o is compiled with -O0 -flto and the final link is compiled
> with -O2 -flto. I would expect div.c is compiled with -O2 -flto, not -O0,
> if div.c is linked in. Am I expecting too much?

  Well, to make that work, wouldn't we have to treat all archives as if they
were opened in --whole-archive mode during stage1, and let the plugin claim
every archive member that contains any IR and then rely on LTRANS to optimise
away all but the used code, right?

  I must admit I don't understand why LTO doesn't emit undefs in the LTO
symtab for builtins.  I think life would be easier all round if the LTO symtab
for main.o contained a reference to __udivdi3 all along, so that we could just
let the usual mechanism pull in all (and only) the needed stuff straight off
in stage1 and not give LTRANS so much redundant work to do.

    cheers,
      DaveK