Reuses translate to locality only if the subsequent use of data occurs before the data are displaced from the cache. Factors that determine if reuse translates to locality include the loop iteration count (since that determines how much data are brought in between reuses), the cache size, its set associativity and replacement policy.

We begin by considering the first two factors: the loop iteration count and
the cache size. In the example above, reuse of `B[j][0]` lies
along the outer dimension. If the iteration count of the innermost
loop is large relative to the cache size (e.g., if the upper bound of
the `j` loop in Figure 2(a) was 10,000 rather than 100),
the data may be flushed from the cache before they are used in the next outer
iteration. It is impossible to determine accurately whether data will
remain in the cache due to factors such as symbolic loop
iteration counts and the other cache characteristics. Instead of
trying to represent exactly which reuses would result in a cache hit,
we capture only the dimensionality of the iteration space that has
data locality [29]. We define the *localized
iteration space* to be the set of loops that can exploit reuse. For
example, if the localized iteration space consists of only the
innermost loop, that means data fetched will be available to
iterations within the same innermost loop, but not to iterations from
the outer loops.

The localized iteration space is simply the set of innermost loops whose volume of data accessed in a single iteration does not exceed the cache size. We estimate the amount of data used for each level of loop nesting, using the reuse vector information. Our algorithm is a simplified version of those proposed previously[23][11][8]. We assume loop iteration counts that cannot be determined at compile time to be small-this tends to minimize the number of prefetches. (Later, in Section 4.2, we present results where unknown loop iteration counts are assumed to be large). A reuse can be exploited only if it lies within the localized iteration space. By representing the localized iteration space also as a vector space, locality exists only if the reuse vector space is a subspace of the localized vector space.

Consider our example in Figure 2(a). In this case, the loop bound is known so our algorithm can easily determine that the volume of data used in each loop fits in the cache. Both loops are within the localized iteration space, and the localized vector space is represented as . Since the reuse vector space is necessarily a subspace of the localized vector space, the reuses will correspond to cache hits, and it is not necessary to prefetch the reuses.

Similar mathematical treatment determines whether spatial reuse
translates into spatial locality. For group reuses, our algorithm
determines the sets among the group that can exploit locality using a
similar technique. Furthermore, it determines for each set its *leading reference*, the reference that accesses new data first and is
thus likely to incur cache misses. For example, of `B[j][0]` and
`B[j+1][0]`, `B[j+1][0]` is the first reference that accesses
new data. The algorithm need only issue prefetches for `B[j+1][0]` and not `B[j][0]`.

In the discussion so far, we have ignored the effects of cache conflicts. For scientific programs, one important source of cache conflicts is due to accessing data in the same matrix with a constant stride. Such conflicts can be predicted, and can even be avoided by embedding the matrix in a larger matrix with dimensions that are less problematic[19]. We have not implemented this optimization in our compiler. Since such interference can greatly disturb our simulation results, we manually changed the size of some of the matrices in the benchmarks (details are given in Section 3.) Conflicts due to interference between two different matrices are more difficult to analyze. We currently approximate this effect simply by setting the ``effective'' cache size to be a fraction of the actual cache size. We will discuss the robustness of this model in Section 4.2 and suggest some further optimizations in Section 6.