libstdc++/8230: Buggy allocator behaviour
Matt Austern
austern@apple.com
Thu Nov 21 03:47:00 GMT 2002
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
More information about the Gcc-prs
mailing list