Re: Cache access at compile time

Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr>
28 Nov 1999 01:31:06 -0500

          From comp.compilers

Related articles
Cache access at compile time abhi@bdc6.cs.iastate.edu (1999-11-16)
Re: Cache access at compile time Daniel.Vogelheim@post.rwth-aachen.de (Daniel Vogelheim) (1999-11-21)
Re: Cache access at compile time Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (1999-11-28)
Re: Cache access at compile time dtruong@irisa.fr (Dan Truong) (1999-12-07)
| List of all articles for this month |

From: Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr>
Newsgroups: comp.compilers
Date: 28 Nov 1999 01:31:06 -0500
Organization: INRIA
References: 99-11-075 99-11-126
Keywords: architecture, performance

> > Can anyone give me pointers to way to ascertain the cache access
> > patterns at compile time.
>
> The Universitaet Saarbruecken has done research to predict cache
> behaviour of programs in order to guarantee upper time bounds in hard
> real time systems.
>
> If I remember correctly they analyzed SPARC binaries and given a
> particular cache architecture classified all memory accesses into
> "always hits", "don't know", or "don't know first iteration, always
> hits afterwards" (for loops). The restrictions for this system were
> quite severe ( ? only static addresses could be predicted ? ), but
> they seemed to work allright for the real time people.
>
> If this sounds like what you want, you can check their papers at:
> http://www.cs.uni-sb.de/~ferdi/publications.html>ache_prediction


Yes,
it was a very interesting work. But the cache behavior prediction was
oriented mainly to instruction cache and scalar acces. A more
interesting problem is to predict the data cache behavior for array
acces in loops (the most serious bottleneck). Ising subscripts will
make the abstract interpretation bit harder. Ferdinand's thesis talk
about this problem and proposed a solution, but its approach was very
restrictive and conservative : I do not see experimental results for
this work (predicting cache miss for array access in a loop).


Regards,


SAAT.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.