HPCwire: Compilers and More: Industrial Strength Interprocedural Analysis

The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing

Leading HPC
Solution Providers

HPCwire >> Features

March 16, 2007

Compilers and More: Industrial Strength Interprocedural Analysis

by Michael Wolfe, Compiler Engineer, The Portland Group, Inc.

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.

Article Tools

Share & Save Options

Discussion

There are 0 discussion items posted.

Join the Discussion

You must be a registered user in order to comment on HPCWire stories.

Members enjoy:

	Access to Special Content, including Podcasts, Webcasts, and Whitepapers and more!
	Ability to take an active role in the discussions that are shaping the HPC technology discipline!
	Special offers available only to HPCWire members!

Become a Registered User Today!

Registered Users Log in Here to Comment

Email Address:	Password (case sensitive)

Remember me	Forgot Password?

RSS Feeds

Feeds by Topic

Feeds by Industry

Feeds by Content Type

Top Headlines

Lustre to Battle Corruption

Oct 07 | GCN.com | Sun Microsystems has been busy building a lot more intelligence into Lustre, a file system used for large-scale cluster computing. Read more...

Oracle and HP's Database Machine Predicated on Voltaire

Oct 06 | The Register | Does the HP Oracle Database Machine represent InfiniBand's big chance to break out its HPC niche? Read more...

3D Imaging Spreads to Fashion and Beyond

Oct 06 | BusinessWeek | A body scan can save a lot of time in the fitting room, and fields from medicine to architecture are adopting 3D computing applications. Read more...

Structural Engineers and Computer Scientists Hope to Integrate Disciplines to 'Revolutionize Building Construction'

Oct 03 | UCSD News | Despite the evolution of computer science over the past 30 years, structural engineering -- hindered by a reluctance to adapt to digital innovations -- has remained relatively unchanged as a discipline. Read more...

Credit Crisis Spreads a Pall Over Silicon Valley

Oct 02 | New York Times | Silcon Valley is starting to feel the effects of the credit crunch. Read more...

Read more headlines...

Featured Whitepapers

Panasas® Tiered Parity™ Architecture

Sep 04 | | Disk drives are approximately 250 times denser today than a decade ago. This is good news for users who are creating, manipulating and storing more data than ever before. It gives them an opportunity to derive more value from their stored data and lowers the capital acquisition and operating expense associated with that data.

View the White Paper Library

Multimedia

Video White Paper: Architecting a Better Network Storage Solution

BlueArc's Titan architecture represents an evolutionary step in file servers by creating a hardware-based file system that can scale bandwidth, IOPS, and overall data capacity well beyond conventional software-based devices. With its ability to virtualize a massive storage pool of up to four usable petabytes of tiered storage, Titan can scale with growing data requirements, offering a competitive advantage for businesses, researchers, or other enterprises seeking to better manage data growth while still ensuring optimal performance.