This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
- From: <tm_gccmail at kloo dot net>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Jonathan Lennox <lennox at cs dot columbia dot edu>,"Joseph S. Myers" <jsm at polyomino dot org dot uk>,Daniel Berlin <dberlin at dberlin dot org>,Ian Lance Taylor <ian at wasabisystems dot com>,Robert Dewar <dewar at gnat dot com>, gcc at gcc dot gnu dot org, drow at mvista dot com,Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Mon, 5 Jan 2004 12:36:37 -0800 (PST)
- Subject: 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