This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Detect cache size with -mtune=native


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]