This is the mail archive of the gcc@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: malloc attributes and realloc


On Fri, 2 Jan 2004, Zack Weinberg wrote:

> Jonathan Lennox <lennox@cs.columbia.edu> writes:
> 
> > Joseph S. Myers writes:
> >> My current draft documentation change for attribute malloc (for this issue
> >> and PR 3414) is
> >
> >>  The @code{malloc} attribute is used to tell the compiler that a function
> >> -may be treated as if it were the malloc function.  The compiler assumes
> >> -that calls to malloc result in pointers that cannot alias anything.
> >> +may be treated as if any non-@code{NULL} pointer it returns cannot
> >> +alias any other pointer valid when the function returns.
> >>  This will often improve optimization.
> >> +Standard functions with this property include @code{malloc},
> >> +@code{calloc} and @code{realloc}.
> >
> > This isn't directly relevant to the current thread, but another aspect of
> > malloc-like functions came up recently: the memory they return is writable.
> > I.e., if char *p was returned by an attribute(malloc) function, then
> >   if (*p != 'a')
> >     *p = 'a';
> >
> > can be safely optimized into
> >   *p = 'a';
> 
> ... that is *not* an optimization; the cache behavior of the latter is
> likely to be worse than the former.
> 
> zw

It really depends on the cache architecture.

If you have a write-back cache where the write miss algorithm results in a
singleton write to memory then a cache line fill, then the former is
better. It will force the memory into cache, then write into the cache
instead, which eliminates the singleton write to memory.

It's mostly older processors which have this (mis)feature - the two which
I know implement this algorithm are the Pentium Classic and the SH7750.
On these processors, it's faster to read the destination memory then write
to it instead of writing to it directly. If you look at the original Quake
source, John Carmack does this in the polygon renderer - that's the reason
why.

On better write-back caches, the write miss results in a cache line
fill then a write to cache. On this type of architecture, the latter is
better because the bus activity is identical and the code for the latter
is shorter.

For a write-through cache, the latter case is better because it eliminates
a possible cache line fill on a read miss.

So, to summarize:

Old-style WBC: case 1 faster
New-style WBC: case 2 faster
          WTC: case 2 faster

The old-style write-back cache is mostly used on older processors, so
personally, I think we should do the optimization.

Toshi



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