> On Sat, Jul 8, 2017 at 1:03 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
> > Hi,
> > PR lto/80838 is about lto+profiledbootstrapped compiler being slower than
> > profiledboostrapped compiler.
> > This is caused by a fact that some of object files linked into cc1plus
> > binary
> > are built with -fPIC and lto-wrapper then decides to make whole binary PIC
> > that
> > is very slow. While we probably ought to avoid linking PIC code into static
> > binary but I saw similar issue with firefox and other programs.
> > I do not think we want to support mixed PIC/non-PIC symbols internally,
> > because
> > it would need quite some work and I do not see any reasonable use cases.
> > This patch makes merging more realistic/agressive. Linking -fPIC and
> > non-PIC
> > code together results in non-PIC binary and thus the corresponding flags are
> > dropped when mismatches occurs.
> > It would be nice to warn about it, but I do not know how to make warning
> > meaningful on targets that are PIC by default.
> > Bootstrapped/regtested x86_64-linux, plan to commit it tomorrow after
> > lto-boottrapping if there are no complains.
> Hum. I wonder if/why we can't ask the linker about the output binary kind?
Hmm, you are right. I forgot I implemented also that :).
I bleieve we need both - disable PIC when linker tell us we can and merge option
so we make sane decisions between pic/PIC, pie/PIE. And of course we have the
wonderful non-plugin path.
I bleieve we got code quality regression here because I forgot about clearing
for non-dynamic builds:
--- lto-lang.c (revision 250245)
+++ lto-lang.c (working copy)
@@ -840,11 +840,13 @@
flag_pie is 2. */
flag_pie = MAX (flag_pie, flag_pic);
flag_pic = flag_pie;
+ flag_shlib = 0;
case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */
flag_pic = 0;
flag_pie = 0;
+ flag_shlib = 0;
I will test this and verify that there is no code quality difference without
the option merging