Debugging Optimized Code

Debugging optimized programs presents special problems. Optimization may change the sequence of operations, add or remove code, and perform other transformations that make it difficult to associate the generated code with the original source statements. For example, the optimizer may remove all stores to a variable and keep it alive only in registers. Most debuggers are incapable of following this and it will appear as though that variable is never updated.

First debug your program, then recompile it with any optimization options, and test the optimized program before placing the program into production. If the optimized code does not produce the expected results, isolate the specific optimization problems in another debugging session.

The following table presents options that provide specialized information, which can be helpful during the development of optimized code.

Diagnostic options
Option Behavior
-qlist Instructs the compiler to emit an object listing. The object listing includes hex and pseudo-assembly representations of the generated instructions, traceback tables, and text constants.
-qreport Instructs the compiler to produce a report of the loop transformations it performed and how the program was parallelized. The option is enabled when -qhot or -qsmp is specified.
-qinitauto Instructs the compiler to emit code that initializes all automatic variables to a given value. We suggest that this option not be used for final production-level code, as it can have a negative performance impact. However, it can be very useful as a debug aid.
-qipa=list Instructs the compiler to emit an object listing that provides information for IPA optimization.

Different Results in Optimized Programs

Here are some reasons why an optimized program might produce different results from those of an unoptimized one:

Related Information:
See -g Option, -qinitauto Option, and Problem Determination and Debugging.
Related Information:
IBM Copyright 2003