The June/July 2009 z/Journal article “Compiling and Debugging Applications on Linux for System z” examined how to compile source code on Linux for System z and how the different tools interact. This article focuses on some advanced optimization issues and security checks and provides insight on how the compiler works internally.
The previous article mentioned the two most important optimization options specific to System z, namely specifying the target processor using -march and -mtune. There are, however, many additional optimization options; some valuable for fine-tuning application performance.
The user manual for GNU Compiler Collection (GCC) 4.4.0 (see the GCC home page at www.gnu.org/software/ gcc/gcc.html) mentions at least 160 code optimization switches that can be individually turned on and off. Users also can specify more than 100 different values controlling the amount of, or determining the context for, applying a certain optimization.
Handling all these options individually wouldn’t be practical for normal application development. So, GCC provides summary optimization options named -O0, -O1, -O2, -O3, and -Os. Option -O0 turns off almost all optimization and is intended for debugging purposes. Option -Os instructs GCC to minimize the size of the generated executable, even if this increases the program’s run-time. In contrast, options -O1, -O2, and -O3 focus on making the executed code fast and activate an increasing number of individual optimizations that have proved generally advantageous.
See the GCC manual for details on what individual optimization techniques are activated by the summary options. These sets of individual optimization switches may, however, vary in future versions of GCC, as new optimizations are added or later processors have different optimization needs. The following set of command line help options cause GCC to tell you what individual settings are activated when applying the summary option -O<level>:
gcc -q -O<level> --help=optimizers
Figure 1 shows the effect the different options have on run-time performance. These times were measured using the SPEC performance benchmark. (The setup is described in a paper by D. Edelsohn et al., titled “Contributions to the GNU Compiler Collection,” available at www.research. ibm.com/journal/sj/442/edelsohn.pdf.)
Turning on at least the first level of optimization with option -O1 greatly reduces program execution time compared to the unoptimized case (option -O0). Enabling further optimization steps by specifying options -O2 or -O3, respectively, has only little effect on program execution time. Optimizing for small executables slightly increases execution time compared to the most aggressive optimization, -O3. However, the effect of individual optimization steps can strongly depend on the nature of the code being compiled. If performance is an important issue, consider fine-tuning by adjusting optimization options. The major optimization options are part of the regression test that every compiler change must pass.