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]

Re: expected_retval attribute proposal


> > I?ve had basically malloc (with inexpected value of NULL),
> 
> Ok, let's take that as an example. There are 526 calls to malloc in
> gcc/*.c (actually, most of them to xmalloc). Of those, only three
> appear directly nested inside 'if ('.
In the case of xmalloc it is problably unfair, since the NULL is already
handled before the function returns.

Also the coding style not recommends to use assignments inside conditionals
so such code is most probably split to two statements.
> 
> In any case, I'd expect the overhead of the malloc implementation to
> be magnitudes larger than the performance difference obtained from
> better branch prediction; the same goes for getc, fputc and other
> common memory management/stdio functions.
I tend to agree.  Maybe getc/putc/eof can be interesting examples, since
the common path overhead is minimal, but there are probably easier to implement
optimizations around.

Honza
> 
> Regards,
> Martin

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