Standard compiler optimization is no longer sufficient for competitive high performance computing. Here we discuss interprocedural analysis (IPA) or whole program analysis, its costs and benefits, and how it affects programmers.

Performance-sensitive programmers are accustomed to building their applications with compiler optimizations enabled. In the past, this might have been as simple as setting the -O option on the command line. Decades of research and experience on compiler analysis and code improvement have produced mature, reliable techniques, the vast majority of which focus on optimizing a single procedure at a time, using redundancy elimination, loop restructuring, register allocation, instruction scheduling, and so on. But it is not enough.

Current highly optimizing compilers all use some form of interprocedural or whole program analysis for best performance. At compile time, the compiler summarizes each procedure in the program; when all procedures are available, the compiler invokes an interprocedural analysis module to collect all the procedure summaries and propagates information from caller to callee and back. While this seems to break the advantages of separate compilation, it is done at link time. The procedures are then optimized using the new interprocedural information. Early implementations used programming environments or special build programs to manage the procedure summaries, which made it hard to migrate from traditional tools, such as make. Current methods are almost invisible, except for the extra time spent at the link step to generate better code using the extra information.

The importance of interprocedural analysis is demonstrated by looking at the SPEC CPU results page (http://www.spec.org/); the base flags for the various compilers all include IPA:

    IBM -O5 (implies -qipa)
    Intel -fast (implies -ipo)
    Pathscale -Ofast (implies -ipa)
    PGI -fast -Mipa=fast,inline
    SGI -Ofast=ip35 (implies -IPA)
    Sun -fast -xcrossfile

We ran the SPEC CPU2000 test suite using the PGI compiler with and without IPA. The performance improvements ranged up to 130 percent speedup, with a 7 percent speedup in the overall geometric mean, demonstrating that IPA is useful and critical to the performance of some applications.

One of the most useful and common benefits of IPA is automatic inlining of procedures, even across source files. Since the compiler has the whole program at link time, it can take a procedure from one object and inline it at a call site in another procedure. This typically reduces the cost of the procedure call, and allows the code for the inlined procedure to be better optimized since the calling context is explicit.

This can also be used to inline or generate special code for calls to system or math libraries. Until link time, it isn’t always known what library a particular procedure will come from. Once it is known that fmax is resolved from libm.a, for instance, the compiler can replace the procedure call by fast inline code.

A less common technique is to create two or more versions of a procedure, each version optimized for a particular calling context. For instance, IPA may generate one version or clone to be optimized for the case when two C pointer arguments are known to be distinct, allowing more vectorization (for instance), and another version for the more general case. The compiler can be directed to replace some calls to the more optimized version where appropriate.

IPA can help optimize around procedure calls even when the call isn’t inlined. IPA may be able to determine that the function is “pure,” meaning that it does no I/O and doesn’t read or write global variables. Code around calls to such functions can be moved above or below the call, since the call won’t interfere with any other code in the caller. This gives the compiler more freedom when scheduling instructions or allocating registers.

Another very common and simple benefit of IPA is recognizing when a procedure argument always has the same value, and replacing the argument by that value to optimize the procedure. The value may be a constant integer, used as a loop limit or in a conditional expression, allowing more aggressive loop optimization or removal of the condition. For C pointer arguments, the value may be an array; using the array directly allows more precise alias analysis, with much of the same benefits as using the C99 ‘restrict’ qualifier. If the constant value is propagated to the procedure, then the caller doesn’t even need to pass that argument, making the procedure call slightly less expensive as well. Even when a procedure argument is not a single constant, it can be useful for the compiler to know when the value of an argument lies in a certain range, or that a pointer only aliases with a limited number of user arrays or variables.

For array arguments (or C pointers to arrays), it is useful on today’s machines to know the alignment of the argument. For instance, to use the packed (SSE) instructions on the x86 or x86-64 architectures, aligned loads can only be used if the data is known to be 16-byte aligned. Knowing the argument alignment allows better code generation for vectorized loops. For dynamically allocated arrays, this means knowing the return alignment of the memory allocation routines.

Modern Fortran includes multidimensional assumed-shape array arguments, which require so-called “dope vectors” to describe the bounds and strides for each dimension. In the general case, the compiler must read these dope vectors for each dimension for each access to the array. IPA can be used to propagate array shapes, replacing dope vector accesses by constant array bounds. This eliminates the dope vector memory accesses, and allows more constant folding at compile time.

Since IPA has a view of the whole program, it can be used to reorganize data in the program as well. One simple example is to reorder the members of a Fortran COMMON block to control the data alignment. This is only safe with IPA, since only then does the compiler know that all instances of the COMMON will be reordered the same way.

Each implementation of IPA is somewhat different. Some compilers depend on interprocedural optimization for performance, while others use IPA mostly to control function inlining. The cost for IPA is spent in program build time, in particular at link time. Some implementations defer essentially all optimization and code generation to link time. This makes the compiler seem quite fast, and the link very slow.

To be accepted by users, the interface to IPA must preserve the edit-compile-link-test development cycle currently in place. Users are unlikely to adopt a new program build mechanism, as proposed in various research projects. IPA must be able to analyze routines in subroutine libraries, which most vendors do not yet fully support. The compiler also needs to know the behavior of routines in the system library, such as ‘malloc’, I/O, and math routines.

Processor architectures have become quite aggressive, with deeply pipelined function units, superscalar instruction issue, out-of-order execution, and integrated vector/multimedia processing units, things which would never have been dreamed of as mainstream during the RISC revolution, for instance. The future offers multicore processors, with heterogeneous cores and function unit customization. Successful performance delivery depends on deep compiler analysis and optimization, which will become more dependent on interprocedural analysis. Bleeding edge programmers need to understand its benefits, potential, and limitations. As has always been true, the best performance is produced when the programmer and the compiler enter into a dialogue, which I will address in a future column.

SPEC (R) is a registered trademark of the Standard Performance Evaluation Corporation (http://www.spec.org/).

—–

Michael Wolfe has developed compilers for over 30 years in both academia and industry, and is now a senior compiler engineer at The Portland Group, Inc. (www.pgroup.com), a wholly-owned subsidiary of STMicroelectronics, Inc. The opinions stated here are those of the author, and do not represent opinions of The Portland Group, Inc. or STMicroelectronics, Inc.