[PATCH] Introduce new gold plugin option "relocation-pic"

[Rafael Espíndola]

On 28 March 2014 11:16, Alexey Volkov <avolkov.intel at gmail.com> wrote:
> Hi Rafael,
>
> Binutils community said that there is no bug in linker
> (https://sourceware.org/ml/binutils/2014-03/msg00233.html)
> Compiler shouldn't rely on output file type to determine what options it
> needed.
> Instead of linker output GCC uses section .gnu.lto_.opts in object files
> with IR to pass compiler options.
> Thus GCC sets pic on Android with LTO enabled.

I don't think that is the direction we want to go fro this case.

> I see in object files with LLVM IR attributes section with target specific
> options:
> attributes #0 = { nounwind uwtable "less-precise-fpmad"="false"
> "no-frame-pointer-elim"="false" "no-infs-fp-math"="false"
> "no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
> "unsafe-fp-math"="false" "use-soft-float"="false" }
> Is it possible to add fpic to those options?

Probably not. These exist for cases we want to support different
options for different functions. For example, we want to compile a
function with avx but another without.

I don't think we ever want to compile a function with PIC and another
without in the same IR file. CCing Nick for a second opinion on this.

In summary, there is a fundamental difference between -fPIC and -mavx.
One should be recorded the IR, the other is a property of the type of
DSO we are building.

If you have to work around this, my suggestion would be to pass -pie
to the linker even when that is the default.

> Also I see that other compiler options such as -O2, -Ofast, funroll-loops
> are not passed through linker to LTO.

These should not be passed. What optimizations are done during lto in
fully independent from what optimizations are done for each
translation unit.

> Thus compiler output with -flto seems to be the same with any optimization
> options.

It should be able to take optimization options during the link. It
should not be aware that -O2 was used to build a given .o.

> Do you have any plans to support these options in LTO?

The optimizations that we should be doing during LTO are fundamentally
different from what we do for each translation unit. What needs to
happen is
* During the processing of each translation unit, optimizations known
that -flto is present, so that they can, for example, avoid excessive
inlining.
* During LTO, we know that basic optimizations have been done. We
don't need to run mem2reg for example.

So we can have a way to pass a *command line option* for the lto link
with -O2 or -O3, but those would not be the same as a translation unit
-O2 or -O3, just the general idea of trying harder to optimize but now
in the linker context, which would result in different passes.

Cheers,
Rafael