Enables the general optimizations such as peephole optimization, common subexpression elimination, pipeline instruction scheduling, dead code elimination, tail recursion and static address elimination. Option qualifiers are also available to target specific types or areas of code for improved performance: -OA, -OI, -OL, -OM, and -OS. When you select any of these suboptions, the compiler automatically enables the basic -O optimization. You can specify any combination of optimizations in any order with a single -O option. For example, -OLMA is equivalent to -O -OL -OM -OA. If you use -O in conjunction with -ansi or -ANSI, the compiler driver automatically sets the -OM option.
Allocates more temporary registers to expression evaluation and fewer to other purposes. The -OE option should be used with programs that have intensive numeric calculations:
rho=exp(-PI*cft/q)+(2*PI*cft*sqrt(1-0.25/q/q));
In statements such as the one above, it is desirable to have enough registers available to hold the result of all intermediate calculations. The -OE option is intended to make more registers available for this purpose. If code does not have intensive numeric computations, the temporary registers will not be needed and thus the -OE option will have the detrimental effect of reducing the number of registers available for other purposes.
Enables algorithmic optimizations. Applies algebraic transformations such as associativity. In some cases, the compiler generates instructions that ignore overflow, underflow, or round-off. Due to the delicate nature of these transformations and the relatively rare opportunity for significant improvement, -OA is not recommended for general use.
Following is an example of C source code and the equivalent code the compiler produces with the -OA option enabled. The following source code:
if (i-5 < 0) printf("%d\n", i);
with algorithmic optimization becomes:
if (i < 5) printf("%d\n", i);
An example of when -OA may produce an unexpected result would be if the variable i is within five of its lowest bound. i-5 "wraps around" and thus is greater than zero, even though i starts out as a negative number, less than five.
Enables automatic inlining for all input source files. The compiler inlines each function which it determines is appropriate for inlining.
Inlining is also performed when a function is called from a file which does not contain its declaration or when the function call appears before the declaration in the same file. This kind of inter-module inlining requires two passes of the compiler.
For example, when compiling the following source modules:
% ccmcore -OI main.c prog1.c prog2.c
The compiler is invoked twice for each of the three source modules. First, the compiler processes each source file to produce an inline file designated by a .inf extension. Then the compiler processes each source using the original source files and the three .inf files.
Functions declared with the __inline keyword (in C and Pascal), the inline keyword (in C++), and OPTIONS/INLINE in FORTRAN are also inlined. This works even if -OI is not thrown. There are a few properties to be aware of. First, these functions are assumed to be of static scope; therefore, they are not exported or available to be inlined in other modules. Second, these functions must be defined in the module before they are called or included in other inline function; otherwise the callers located before the function definition will not be able to inline them. Third, these functions are not output in closed form if they were successfully inlined by all their callers.
Since the __inline keyword defines a static function, a function declared in a single module with the __inline keyword cannot be inlined into multiple modules. However, there are two techniques that can be used to inline a function into multiple modules, even when the compiler chooses not to do so automatically. The first is that the function can be declared with __inline near the top of each module where it is used; this process can be made easier by putting the __inline function into a file that is included by each source module that needs it. The second is to use the -OI=funcname option, described below, without the use of the __inline keyword. Users may also consider using the -OD=funcname option in conjunction with this second technique.
Inlines the functions listed on the command line and any functions specifically marked for inlining. No automatic inlining is done. For example, when compiling the following source code:
% ccmcore -OI=sub main.c prog1.c prog2.c
The compiler inlines the routine sub() when called, along with calls to any routines specifically marked for inlining.
c.c: extern int a(), b(); int c() { return a() + b(); }
a() and b() will be inlined automatically because of -OI.
a() and b() will both also be output in their defining modules.
a() will be inlined automatically because of -OI=a.
b() will not be inlined because -OI was not thrown.
Both a() and b() will be output in their defining modules.
o ccmcore -OI=a -OD=a a.c b.c c.c
a() will be inlined automatically because of -OI=a
b() will not be inlined because -OI was not thrown.
a() will not be output in closed form, but b() will.
o ccmcore -OI=a -OI -OD=a a.c b.c c.c
a() will be inlined automatically because of -OI=a
b() will be inlined automatically because -OI was thrown.
a() will not be output in closed form, but b() will.
/* lots of code in here, not shown for brevity... */
return a_very_big_function() + b() + c();
a_very_big_function() will not be inlined even though -OI is thrown because the compiler deems it to be too large.
b() will be output because -OI is thrown and it is small.
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module a. c() will not be output in closed form because it declared with __inline and it was was successfully inlined everywhere.
o ccmcore -OI=a_very_big_function a.c b.c:
a_very_big_function() will be inlined because of -OI=a_very_big_function
b() will not be inlined because -OI was not thrown
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module
a. c() will not be output in closed form.
a_very_big_function() and b() will not be inlined because -OI was not thrown.
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module a. c() will not be output in closed form.
Enables loop optimizations. With this optimization, the compiler concentrates most of its resources to optimizing code in the innermost loops in your source files. Therefore, this option is most effective for code containing many loop structures which are executed frequently. This optimization includes strength reduction, loop invariant analysis, and loop unrolling. Where code size is a priority, you can disable loop unrolling. Also, you can increase the maximum number of times the loop is unrolled. See the other options in this section.
Performs loop optimization only for the functions listed on the command line. For example, the following command line specifies loop optimization only for the function sub:
% ccmcore -OL=sub main.c prog1.c prog2.c
Increases maximum for loop unrolling from 4 to 8 times and applies unrolling to larger loops than usual.
Increases maximum for loop unrolling from 4 to 8 times. This option requires the -OL option.
Enables memory option. This option is equivalent to -O except it allows the optimizer to assume that memory locations do not change, except by explicit stores, and are not affected by any external sources.
This compile-time option is not safe in applications where memory is externally affected, such as in device drivers, operating systems, and shared memory. This option is also not safe in a non-virtual memory environment when interrupts are enabled.
This option is enabled automatically when -O is used with either -ansi or -ANSI. The volatile keyword explicitly indicates any objects which may change without the compiler's knowledge or control. If for some reason you cannot use the volatile keyword, you can use the -Onomemory option, which disables memory optimization while enabling other -O optimizations.
Specifies a list of functions whose code generation may be skipped during the compilation phase, thereby reducing code space. For example:
specifies that the compiler should not generate code for the functions foo and bar. This can be useful if a postprocessing tool determines that these functions are never called.
The -OD option can also be useful with inlining. For example:
specifies that foo and bar will be inlined where ever they are called and because of that, the actual code generation for the functions may be omitted. If for some reason a function listed could not be inlined at one of the call sites, the linker will not be able to resolve the missing symbol, resulting in a link-time error.
c.c: extern int a(), b(); int c() { return a() + b(); }
a() and b() will be inlined automatically because of -OI.
a() and b() will both also be output in their defining modules.
a() will be inlined automatically because of -OI=a.
b() will not be inlined because -OI was not thrown.
Both a() and b() will be output in their defining modules.
o ccmcore -OI=a -OD=a a.c b.c c.c
a() will be inlined automatically because of -OI=a
b() will not be inlined because -OI was not thrown.
a() will not be output in closed form, but b() will.
o ccmcore -OI=a -OI -OD=a a.c b.c c.c
a() will be inlined automatically because of -OI=a
b() will be inlined automatically because -OI was thrown.
a() will not be output in closed form, but b() will.
/* lots of code in here, not shown for brevity... */
return a_very_big_function() + b() + c();
a_very_big_function() will not be inlined even though -OI is thrown because the compiler deems it to be too large.
b() will be output because -OI is thrown and it is small.
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module a. c() will not be output in closed form because it declared with __inline and it was was successfully inlined everywhere.
o ccmcore -OI=a_very_big_function a.c b.c:
a_very_big_function() will be inlined because of -OI=a_very_big_function
b() will not be inlined because -OI was not thrown
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module
a. c() will not be output in closed form.
a_very_big_function() and b() will not be inlined because -OI was not thrown.
c() will be inlined because it was declared with __inline in the same module as the caller.
a_very_big_function() and b() will be output in closed form in module a. c() will not be output in closed form.
Enables space optimizations. This option invokes all the basic optimizations except those that would increase the code size. The compiler generates smaller code, with potential for decreased performance. -OS implies -Onostrcpy. If -OS is specified, calls to strcpy() will not be inlined. Inlining strcpy() takes more space but can improve program speed. -OS disables loop unrolling (-OL).
Disables the -OS option when both -OS and -OT are on the command line and -OS is before -OT.
The options beginning with -Ono disable certain optimizations. Each enables the same general optimizations specified by the -O option but turns off a specific optimization enabled by -O.
Disables propagation of constant expressions. Constant propagation is the replacement of one or more variables with constants over a portion of a variable's lifetime in which the variable's value is known and does not change.
Disables common subexpression elimination.
Disables memory optimizations.
For use with C and C++. Suppresses the optimization generating special code for minimum, maximum, and absolute value expressions of the form:
(i < j) ? i : j (i > j) ? i : j (i < 0) ? -i : i
Disables peephole optimizations.
Disables instruction resequencing for pipelined architectures.
For use with C and C++. Suppresses optimizations generating inline code for strcpy() and strcmp() with constant arguments.
Disables tail recursion, a general optimization enabled with the -O option. In a recursive procedure, tail recursion optimization replaces the procedure call with a branch instruction and eliminates the return statement.
Disables loop unrolling, a part of the -OL optimization. If -OL is not specified, -Onounroll is the same as -O. If -OL is specified, all loop optimizations except unrolling are performed.