Page 188
OPTIMIZATION OPTIONS
These options control various sorts of optimizations:
| _O, _O1 |
Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for
a large function. Without _O, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: If you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code. Without _O, only variables declared register are allocated in registers. The resulting compiled code is a little worse than produced by PCC without _O. With _O, the compiler tries to reduce code size and execution time. When you specify _O, the two options _fthread_jumps and _fdefer_pop are turned on. On machines that have delay slots, the _fdelayed_branch option is turned on. For those machines that can support debugging even without a frame pointer, the _fomit_frame_pointer option is turned on. On some machines other flags may also be turned on. |
| _O2 | Optimize even more. Nearly all supported optimizations that do not involve a space-speed tradeoff are performed. Loop unrolling and function inlining are not done, for example. As compared to _O, this option increases both compilation time and the performance of the generated code. |
| _O3 | Optimize yet more. This turns on everything _O2 does, along with also turning on _finline_functions. |
| _O0 |
Do not optimize. If you use multiple _O options, with or without level numbers, the last such option is the one that is effective. |
Options of the form _f flag specify machine-independent flags. Most flags have both positive and negative forms; the negative form of _ffoo would be _fno_foo. The following list shows only one form—the one which is not the default. You can figure out the other form by either removing no_ or adding it.
| _ffloat_store |
Do not store floating-point variables in registers. This prevents undesirable excess precision
on machines such as the 68000 where the floating registers (of the 68881) keep more
precision than a double is supposed to have. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use _ffloat_store for such programs. |
| _fmemorize_lookups | Use heuristics to compile faster (C++ only). These heuristics are not enabled by default, |
| _fsave_memorized |
since they are only effective for certain input files. Other input files compile more slowly. The first time the compiler must build a call to a member function (or reference to a data member), it must (1) determine whether the class implements member functions of that name; (2) resolve which member function to call (which involves figuring out what sorts of type conversions need to be made); and (3) check the visibility of the member function to the caller. All of this adds up to slower compilation. Normally, the second time a call is made to that member function (or reference to that data member), it must go through the same lengthy process again. This means that code like this: cout << "This " << p << "has"<< \ << " legs.\n" makes six passes through all three steps. By using a software cache, a hit significantly reduces this cost. Unfortunately, using the cache introduces another layer of mechanisms which must be implemented, and so incurs its own overhead. _fmemorize_ lookups enables the software cache. Because access privileges (visibility) to members and member functions may differ from one function context to the next, g++ may need to flush the cache. With the _fmemorize_lookups flag, the cache is flushed after every function that is compiled. The _fsave_memorized flag |