The effective use of processor caches is crucial to the performance of applications. It has been shown that cache misses are not evenly distributed throughout a program. In applications running on RISC-style processors, a small number of delinquent load instructions are responsible for most of the cache misses. Identification of delinquent loads is the key to the success of many cache optimization and prefetching techniques. In this paper, we propose a method for identifying delinquent loads that can be implemented at compile time. Our experiments over eighteen benchmarks from the SPEC suite shows that our proposed scheme is stable across benchmarks, inputs, and cache structures, identifying an average of 10 % of the total number of loads in the benchmarks we tested that account for over 90 % of all data cache misses. As far as we know, this is the first time a technique for static delinquent load identification with such a level of precision and coverage has been reported. While comparable techniques can also identify load instructions that cover 90 % of all data cache misses, they do so by selecting over 50 % of all load instructions in the code, resulting in a high number of false positives. If basic block profiling is used in conjunction with our heuristic, then our results show that it is possible to pin down just 1.3 % of the load instructions that account for 82 % of all data cache misses. 1.

Memory references in an instruction stream often pose a challenge for performance improvements on high-performance microprocessors. One common scenario is that a load and a sequence of dependent instructions are on a critical path, but scheduling these instructions early to reduce the critical path length is often hindered by a preceding store, which may write to the same memory location as the load. A traditional memory disambiguation approach employed by a compiler may break such a potential dependence only if it can successfully disambiguate the memory locations referenced by the store and the load. This conservative treatment in memory disambiguation is greatly alleviated by a recent architectural support for data speculation. With such a support, a load can be freely moved up across an aliasing store, and if the alias does occur, it is detected by a run time check and a recovery code will be invoked to re-execute the speculated instructions. Data speculation opens...

CONTENTS Page 1. INTRODUCTION : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 2. BACKGROUND : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2.1 Overview of the IMPACT Compiler : : : : : : : : : : : : : : : : : : : 5 2.2 Overview of the IMPACT Simulation Environment : : : : : : : : : : 8 2.3 Dependence Analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 2.3.1 The IMPACT Memory Dependence Tracking System : : : : : 12 2.4 The MCB Data Speculation Approach : : : : : : : : : : : : : : : : : 13 3. DATA SPECULATIVE OPTIMIZATIONS : : : : : : : : : : : : : : : : : : 17 3.1 Preload and Verify : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17 3.1.1 Loop invariant data speculative optimizations : : : : : : : : : 19 3.1.2 Load-subroutine advancement optimization : : : : : : : : : : :<F