A crucial problem is dealt with in this paper. When the first higher-level languages—for example, Algol 60—were designed, contemporary hardware architectures were an obstacle to efficient implementation, because they lacked efficient means for addressing variables located in the execution stack. New architectures were designed in order to improve this situation.
Later, programming languages were designed to facilitate an efficient and secure implementation on extant architectures. For example, the design of Ada tried to limit the possibility of aliases—different names for a single location—and it forbade them completely for named variables. This provided easy-to-use registers for frequently used variables, thus improving performance.
Two different events made all of this obsolete. The first one is the design of the language C, and the importance of this language as a ubiquitous medium-level implementation language. C encourages the use of aliases. Tracking them during compilation is extremely difficult. The second event is that, in order to improve processor performance, hardware designers invented extremely complicated architectures, which are no longer intended to make compilation an easy task.
The best (or worst) example of this is the IA-64 architecture, designed jointly by Intel and HP. Here, and contrary to the DEC Alpha architecture, trying to get the peak performance from the processor is entirely the responsibility of the compiler, and it is an almost impossible task. Preparing instruction bundles so that they can be executed simultaneously is a very difficult task, but speculative execution for data access is worse. To use it, you need to anticipate what data will be needed in registers, and what instructions will be executed, in order to prepare them in advance. Then, when the data is needed, or when the proper branch is taken, all is ready to go.
The ideal way to do this would be to execute the program with its final input data, completely monitor its execution, and then generate optimal code. All attempts to avoid this suppose that either you monitor the execution on sample (but hopefully significant) data, or you use good heuristics to avoid this. Of course, the resulting solution is suboptimal. In fact, it is likely that programs running on an IA-64 use at best a fraction of the theoretical peak performance.
This paper is a presentation of some solutions used in the Intel Open Research Compiler. It is readable and interesting, although it has some defects: the assumed background is not even mentioned, thus the reader is supposed to already know some important characteristics of the IA-64 architecture; the English is not perfect, with many typographical errors and bizarre constructions; all of the tests are only carried out on a subset of the SPEC2000 benchmarks, as if the only purpose of the work was to efficiently compile only these programs; and, finally, the performance improvements resulting from this extremely clever and complicated work are really disappointing, since they are never better than 12 percent. Generating efficient code for the IA-64 is still an enormous challenge. This paper is a good contribution, but clearly much additional work will be needed.
