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


"Kaveh R. Ghazi" wrote:

> I know.  I did three tests:
> 
> 1. Removing the attribute from gcc sources to see the existing gain:
> http://gcc.gnu.org/ml/gcc/2004-01/msg00107.html
> http://gcc.gnu.org/ml/gcc/2004-01/msg00116.html
> 
> 2. Add the attribute to xrealloc in include/libiberty.h:
> http://gcc.gnu.org/ml/gcc/2004-01/msg00160.html
> 
> 3. Add the attribute to ggc.h (which slows down GCC!):
> http://gcc.gnu.org/ml/gcc/2004-01/msg00163.html
> 
> I believe #2 addresses the effect of using the attribute on realloc
> since GCC uses xrealloc everywhere it meant to use realloc semantics.

The source base still has quite a few references to plain "realloc",
but that's a nit.  I also missed that reference.  Now we know that
your results showed a 0.005 improvement for in one sample and a
slowdown of 0.017 in a slightly different test on another sample.
It would seem inappropriate to consider this a strong case for the
optimization.  :-)  With the one-case improvement so minute, I need
to ask about your methodologies for controlling for outside interference
and caching effects and so on.  It would take some real work to
show that the malloc attribute for realloc would have a measurable
effect on the one sample program of GCC, given such a small change.

Another approach might simply be to say, "realloc has traditionally
been used in way that can not allow the compiler to presume that all
old aliases are now invalid.  Therefore, let there be a new function,
"realloc_noalias" (pick your suffix) that does have exactly this
implication in its usage."  We could all be happy then.

Cheers - Bruce


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