GNU GCC compiler optimization question

Hello,

I have a question regarding compiler optimization of a cross compiler GCC (m68k). We are using version 3.4.0. When activating compiler optimization with the options =84- O1, -O2, - O3 =93 there is a number of individual optimization flags set in the background. With =84- O1 =93 there are, as in the GNU documentation described, at least 10 optimization flags (-funit-at-a-time, -fomit- frame-pointer, -fdefer-pop, -fmerge-constants, -fthread-jumps, -floop- optimize, -fif-conversion, -fif-conversion2, -fdelayed-branch, -fguess- branch-probability, -fcprop-registers).

The following sentence in the GNU documentation makes us very curious : Chapter =933.10 Options That Control Optimization=94 -> =84Not al= l optimizations are controlled directly by a flag. Only optimizations that have a flag are listed. =93

Does anyone have experience what are the additional optimizations? Is there a description existing? Why is it not possible to control them via flags?

Thanks for your help.

Reply to
Karl-Heinz Rossmann
Loading thread data ...

gcc has a very large number of flags (especially later versions - 3.4.0 is quite old now) for enabling and disabling optimisations, and for tuning parameters. But there will be plenty of small optimisations where it is simply not worth having a flag (including all the documentation that must go with it) since no one is likely to want to enable or disable them individually, and very few people will be interested in the details. For most users, the -Ox flags give the easiest way to pick optimisation levels. Sometimes it can be useful to explicitly specify other flags (such as for more or less loop unrolling). But flags like "-fcprop-registers" are normally only of interest to gcc developers and testers - details of non-flagged optimisations are even less relevant to normal users.

So if you really want to know the fine details, you'll probably want to look at the gcc source code. There may also be some information in the "gcc internals" documentation on the gcc web site, and the gcc developers mailing lists might be some help (search the archives before asking!).

Reply to
David Brown

Hello:

Given that the "-Ox"s are grab bags of optimizations, it makes a lot of sense that not all of them, especially those which may be unsafe in some circumstances, not be included. The "use if you know what you're doing" flags, in particular, probably don't belong in a grab bag.

Example:

(from

formatting link
imize-Options)

--start of quote--

-funsafe-math-optimizations Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.

This option is not turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. Enables -fno-signed-zeros, - fno-trapping-math, -fassociative-math and -freciprocal-math.

--end of quote--

Now, most of us write code which do not depend on an exact implementation of IEEE floating point arithmetic, and in addition (;-)) run well debugged code running on well-conditioned data. Such flags, then, are possibly useful.

Other flags are useful for people with a priori knowledge of the behavior of the code when used on the target data and chip.

(I hope this was useful.)

Nicolas Robidoux Universite Laurentienne

all

Reply to
superstackswing

For embedded code, use -Os or -O2 and be happy.

The remaining tweaks may produce marginally better code, but you have to get the assembly listings and compare the results with the particular flag on and off.

A much better optimization was changing from GCC 3.xx to GCC 4.xx. For my ARM code shrunk in the avreage by 10% (several hundreds of kbytes of raw code).

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

If you really want to see what optimizations are valid simply run:

$ touch test.c $ test.c -Os -S -fverbose-asm -o test-Os.s $ test.c -O0 -S -fverbose-asm -o test-O0.s $ test.c -O1 -S -fverbose-asm -o test-O1.s $ test.c -O2 -S -fverbose-asm -o test-O2.s

Now you can diff the *.s files and search for flags you don't want and manipulate them on the command line.

jbe

Reply to
Juergen Beisert

Thank you for all the answers. Maybe I have to add some details to my first question. I am working in the aerospace domain (DO-178B). If we want to use optimizations it is necessary for us to know exactly what kind of optimization is done. Therefore we also need to know _every_ optimization in detail. Otherwise we cannot guarantee if the compiler doesn't introduce some features into the assembler code which are e.g. not deterministic. Is there any possibility to get a list of _all_ available optimizations without digging in the source code of GCC?

Reply to
Karl-Heinz Rossmann

Have you tried asking the vendor you purchased your DO-178B-certified version of gcc from?

Reply to
Hans Odeberg

I don't think such information makes sense for *any* compiler. It is meaningless to try to say what is an "optimisation" - there is no line that can be drawn between "code generation" and "optimisation".

The gcc source code will let you see *exactly* how the source code is generated, if you are willing to spend enough time studying it.

Otherwise, I'd recommend a macro assembler.

Of course, you could just find a compiler (gcc or otherwise) supplier with appropriate certification, or a third-party that can do such certification. Or you could do appropriate testing of the compiler, tools, and application yourself.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.