top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

-flto making program slower in gcc/g++

0 votes

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 with the remaining object files to produce the final application, which is about 100MB big. We are using GCC 4.7.2 with a non-GOLD 2.23.1 binutils.

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

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

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?

If it helps, when I add "-fuse-linker-plugin" I get this error:
g++: error: -fuse-linker-plugin is not supported in this configuration

posted Jun 11, 2013 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button
I ran into similar issue but I got no response here.

My guess is
that flto makes your average run time smaller.  But I guess most people  use it in a hope of making their critical pathes running faster, which are benchmarked.
Let me clarify then. The benchmark consisted of a few dozen runs of the program each with different inputs, with the average time given. For this program, each run typically takes a few hours so there's little risk of sample error.

Similar Questions
0 votes

If I compile my embedded program with options "-g -O1" I obtain an elf file with debug information. I can objcopy the elf file to a binary or hex file that can be loaded to flash, effectively striping out the debug
information leaving only the optimized code in ROM.

But if I re-build with options the same except omit the -g option, obviously I will have no symbols in the elf file making debugging impossible or at least more difficult. However, when I object copy this elf to a binary or hex file they are different somewhat than the binary or hex produced with options -g present. At least with 4.7.3 the main difference, as seen with objdump, is in the prologue to certain function calls with only a few bytes different in total code length on a fairly large embedded application (arm). So -g has some effect on the actual code produced it appears.

Is this difference expected? Should -g cause changes in the actual code generated and not just add debug symbols to the elf? Possibly it is related to the optimization level? I have not checked to see if the
results differ with higher or lower levels than -O1.

I have seen several opinions regarding this but no authoritative answer. The gcc manual also does not really answer this.

+2 votes

I am getting following error when compiling my program with gcc version 4.9.0

gcc --version
gcc (GCC) 4.9.0 20131023 (experimental)


./A.out: /usr/lib/x86_64-linux-gnu/ version `CXXABI_1.3.8' not found (required by ./A.out)

But I gcc 4.7.3 is fine. Any guess why this may be happening.

0 votes

How can we debug the segmentation fault in a program which has been compiled without "-g" option?

+1 vote

I'm on /dev/sda7. I want to install gcc with C++ support in /dev/sda2.

  1. Is it possible to install gcc in /dev/sda2?
  2. What are the dependencies to install gcc? Or which packages should I install there in /dev/sda2 before installing gcc?
  3. What is cross compiler? How can I install gcc as cross compiler? When do we need to install gcc as cross compiler?
  4. Can someone explain the method of installing cross compiled gcc?