Re: libstdc++/8230: Buggy allocator behaviour

[Matt Austern <austern@apple.com>]

The following reply was made to PR libstdc++/8230; it has been noted by GNATS.

From: Matt Austern <austern@apple.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Benjamin Kosnik <bkoz@redhat.com>, bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   jkanze@caicheuvreux.com, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: libstdc++/8230: Buggy allocator behaviour
Date: Thu, 14 Nov 2002 14:10:55 -0800

 On Thursday, November 14, 2002, at 12:39 PM, Gabriel Dos Reis wrote:
 
 > Benjamin Kosnik <bkoz@redhat.com> writes:
 >
 > | See attached patch for a way to fix this with the pool allocators.
 >
 > I agree with your patch.
 >
 > The following comment is for possible improvements.  What about using
 >
 >    if (__builtin_expect(__ret == 0, 0))
 >        __throw_bad_alloc("allocate::allocate");
 >
 > ?
 > That gives a hint to the compiler that the branch is expected to be
 > taken very unfrequently, and it should make scheduling accordingly.
 >
 > In general, I would like to see us starting using use 
 > __builtin_expect()
 > at places where we do checks for limits cases.  Thoughts?
 
 Two questions.
 
 First, is it known how much of a speedup this gives on typical 
 platforms?
 
 Second, if the answer to question 1 is "a lot": is there some sensible
 way to use this in the compiler itself?  I suppose it'd have to involve
 some ghastly macro hackery because of the bootstrap problem, but
 it we're talking big performance wins, it might be worth it.
 
 			--Matt