Menu
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.
378
GCC has a range of optimization levels, plus individual options to enable or disable particular optimizations. The overall compiler optimization level is controlled by the command line option -On, where n is the required optimization level, as follows: -O0 . (default).
The compiler optimizes to reduce the size of the binary instead of execution speed. If you do not specify an optimization option, gcc attempts to reduce the compilation time and to make debugging always yield the result expected from reading the source code.
-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.
116
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
