This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Detect cache size with -mtune=native
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 1 Mar 2007 11:06:20 +0100
- Subject: Re: [patch] Detect cache size with -mtune=native
- References: <20070226011328.GA3018@atrey.karlin.mff.cuni.cz> <20070227151924.GA12761@atrey.karlin.mff.cuni.cz>
Hello,
> > this patch extends -mtune=native to detect the size of the l1 cache and
> > of the cache line, and to pass it to the compiler by params. I have
> > tested this on several machines to that I have access, and the results
> > seem to be correct (but especially the intel way of describing the cache
> > sizes is quite ugly.
> >
> > Bootstrapped & regtested on i686.
> >
> > Zdenek
> >
> > * config/i386/driver-i386.c (describe_cache, detect_caches_amd,
> > decode_caches_intel, detect_caches_intel): New functions.
> > (host_detect_local_cpu): Use detect_caches_amd and
> > detect_caches_intel.
>
> OK, thanks, just two minor questions.
> > + /* We approximate the effects of associativity by considering the cache to be
> > + (1 - 1/2^assoc) times smaller. */
>
> Hmm, is this realistic? I know that we don't have page coloring but
> still for continuous arrays we are interested in, the associativity of
> caches should not be major limiting factor..
you are right, it certainly depends on the context; I guess that in
loop
for (x)
for (i)
use (a[c][i]);
the cache will behave the same way regardless of the associativity, while in
for (x)
for (i)
use (a[i][c]);
the 1-1/2^assoc factor might be realistic. I will pass the full size of
the cache to gcc for now, if someone implements cache modeling, he may
decide how to deal with it then.
Zdenek