Raul_Silvera

In a couple of previous posts ( TOC Overflow: what is it, and why should you care?, Dealing with TOC overflow: the traditional approach ) I have presented the issue of TOC overflow. Now I will discuss some features of the XL compilers that can help bypass TOC overflow while minimizing any negative effects on runtime performance.

1. Minimal TOC: The option -qminimaltoc makes the compiler generate code that uses a single entry in the TOC for each compilation unit (in C/C++ a compilation unit is a source file). In order to do this, a separate level of indirection must be follow in order to access TOC-based variables. This means that the program will be larger and slower than if it did not have TOC overflow, but it will still be faster than using the -bbigtoc option. This is similar to the -mminimal-toc from gcc.

Furthermore, -qminimaltoc does not need to be used on all compilation units, so you can minimize the performance impact by using this flag only on compilation units that are not relevant for performance.

2. IPA: IPA is short for inter-procedural analysis, a form of compiler optimization that looks at the whole program, not just a single compilation unit. For this, the optimizer is invoked during the linking phase of your application, to perform transformations that can affect multiple compilation units.

Applying this process significantly reduces TOC pressure, and in most cases completely eliminates TOC overflow. It does so by restructuring your program to reduce the number of global symbols. The result is similar to what could be achieved through source changes, but avoiding the widespread manual source changes.

In the XL compilers, IPA is implied at optimization levels -O4 and -O5, but those also include other complex optimizations which may not be as relevant to commercial application development. One good alternative is the option -qipa=level=0, which applies a minimal level of whole-program optimization. This is often sufficient to eliminate TOC overflow, but in very large applications you may need -qipa=level=1 instead, which will perform a more aggressive reduction of the TOC requirements, at the cost of a longer compilation process.

Note that for whole-program analysis to be performed, the -qipa option needs to be specified both at the compile and link command lines. This means that the linking of the program has to be done through the compiler driver (xlc, xlC or cc) instead of directly through the system linker (ld). For maximum effect, all source files should be compiled with -qipa, but it is possible to mix-and-match objects compiled with different options and have them interoperate.

If you try these options please add comments to this post describing your results.

When building large applications on AIX or pSeries Linux you may have experienced the dreaded TOC overflow. This is a situation reported the system linker that causes it to abort and fail to generate an executable.

What is this situation and what are the strategies for coping with it?

Basically, the TOC or table-of-contents is a table that the program uses to reference global symbols. Since these symbols can be referenced from multiple object files, their memory location is unknown until link time, so the code generated by the compiler to access them must look them up in this table.

The way this works is that the ABI reserves a register which always points to the TOC. The compiler generates an indirect reference off this pointer with a zero offset, which is updated by the linker with the actual offset it selected for each global symbol. The PowerPC architecture allows up to a 64K offset, thus creating a limit of 16K global symbols on 32-bit mode and 8K on 64-bit mode. If a program has a larger number of global symbols the linker cannot reserve TOC slots for all of them, and it aborts after reporting TOC overflow.

On my next post I'll discuss some strategies for addressing this problem, and their tradeoffs. Here's a link: Dealing with TOC overflow: the traditional approach