9

I'm constrained by a 128Kb limit executable size for an embedded PowerPC system. Unfortunately, using option -Os to optimize for size does not work due to what I believe is a compiler bug (link with -Os fails due to undefined reference to _restgpr_30_x and similar), while with -O[123] everything links fine. This is with gcc 4.8.1 host=i86, target=powerpc-wrs-vxworks.

My next idea is to use the various optimization options selectively. But which of these options would reduce code size instead of execution time? I went on to use some options in isolation and found that -O2 in addition with

-fno-caller-saves
-fno-cse-follow-jumps
-fno-hoist-adjacent-loads
-fno-inline-small-functions
-fno-optimize-sibling-calls
-fno-peephole2
-fno-reorder-functions
-fno-rerun-cse-after-loop
-fno-tree-vrp
-fno-reorder-blocks
-fno-tree-vect-loop-version

reduces code size when used. Is there a more systematic approach than experimenting? The GCC docs describe the various options, but don't say if they are more geared towards execution time speedup or code size reduction.

Jens
  • 69,818
  • 15
  • 125
  • 179
  • 1
    [This page](http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) tells you pretty much everything you need to know. – Paul R Oct 21 '13 at 10:25
  • `-Os` should be the way to go. If that has unresolved symbols, your installation is buggy, not necessarily your compiler. Eg. in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53803 they suggest that this is ulibc bug. Did you compile the c library in question yourself? – Jens Gustedt Oct 21 '13 at 12:27
  • @JensGustedt No, we link with the vxWorks 5.4 library as shipped by Wind River. – Jens Oct 21 '13 at 12:50
  • 1
    possible duplicate of [Process for reducing the size of a executable](http://stackoverflow.com/questions/200292/process-for-reducing-the-size-of-a-executable) – mlt May 31 '15 at 22:06
  • many of these are totally redundant and already enabled at Os and O2 – Evan Carroll Nov 09 '18 at 05:25

3 Answers3

1

-Os enables all -O2 optimization apart from :

-falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version

Keep in mind that -Os makes gcc perform other operations to reduce the size so it might not be enough.

Zild
  • 61
  • 1
  • 4
1

The only significant size difference I have ever achieved is by using -s.

Using only that, an executable of mine just shrunk from 90 KB to 40 KB. Various options mentioned in the question only further reduced it to 39 KB.

Many of these options as they relate to size are described here but again - I've tried them in the past and none of them (aside from -s) had a significant impact.

AndyO
  • 1,512
  • 20
  • 28
0

You can strip your build binary to further remove all debugs.

  1. First build using your default settings.
  2. After build complete strip binary.

    your_toolchain-strip a.out

e.g. arm-none-linux-gnueabi-strip a.out

Chirag Desai
  • 1,249
  • 1
  • 10
  • 22
  • Thanks, but this is not the issue. The issue is the size of the text+data segments. – Jens Oct 21 '13 at 12:52