Thanks for the help! Some responses:
> I have to admit that I do not understand the last two sentences: Are the object files (.o) in a shared library (.so, .dyn, .dll) or in a static library (.a)?
The final executable is created from a mix of .o and .a files. Do I
need to specify -flto when creating the static libraries too or just
when creating the final executable?
> I think without -fuse-linker-plugin no functions can be inlined from static libraries (.a) but only from object files (.o).
Any idea why GCC is returning this error when provided this option? Do
I need to explicitly specify --enable-lto when configuring GCC? Using
strace, I verified that LD 2.23.1 is being used by GCC and when
looking at the help for that version I see that there is a "-plugin"
option. GCC seems to be returning this error without even calling LD,
though, so I don't think LD is the problem. What else could cause GCC
to return this error?
On Wed, Jun 12, 2013 at 4:23 AM, Tobias Burnus <burnus@xxxxxxxx> wrote:
> Uri Moszkowicz wrote:
>>
>> I'm having trouble with link time optimization in my application. It
>> is a large application that uses only basic C++ (no exceptions, no
>> templates, no STL, no floating point, etc). Like many applications,
>> the source files are compiled separately into object files. Some of
>> those are combined into shared libraries. The shared libraries are
>> then statically linked
>
>
> I have to admit that I do not understand the last two sentences: Are the
> object files (.o) in a shared library (.so, .dyn, .dll) or in a static
> library (.a)?
>
>
>> I simply added "-flto" to the GCC command to create object files:
>> g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic
>> --no-exceptions -fPIC -c some.cc
>>
>> I then added "-flto" to the final link command but not the shared
>> libraries:
>> g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a
>> -Wl,--wrap,open -flto
>
>
> You should also enable optimizations at linkage time (-O3 -mtune=generic
> etc.); otherwise, LTO might not do as much optimizations as you would like
> it to do.
>
>
>> I ran a benchmark of tests and the resulting execution time is now
>> about 7% higher than it was without "-flto" added. Any suggestions for
>> how to improve this result or why it may have gotten slower?
>
>
> Except for the issue mentioned above, think the most likely problem is that
> too much inlining is done. Inlining is not always profitable, e.g. not for
>
> for (....)
> {
> if (something very unlikely)
> some_func()
> do something ...
> }
>
> Here, inlining "some_func" will fill the cache with rarely executed code.
> The compiler (developers) try to apply inlining carefully (e.g. growth
> limits) but it's all based on heuristics.
>
> With LTO you enable optimizations between files and, hence, inlining. On
> average, it should be profitable. But it might also lead to inlining
> functions which shouldn't be inlined.
>
>
>
>> If it helps, when I add "-fuse-linker-plugin" I get this error:
>> g++: error: -fuse-linker-plugin is not supported in this configuration
>
>
> I think without -fuse-linker-plugin no functions can be inlined from static
> libraries (.a) but only from object files (.o).
>
> Tobias
