This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add malloc predictor (PR middle-end/83023).
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Martin Liška <mliska at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <hubicka at ucw dot cz>, Nathan Sidwell <nathan at acm dot org>
- Date: Wed, 1 Aug 2018 14:25:31 +0200 (CEST)
- Subject: Re: [PATCH] Add malloc predictor (PR middle-end/83023).
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking at how widely it is going to apply, I noticed that the default, throwing operator new has attribute malloc and everything, but the non-throwing variant declared in <new> doesn't, so it won't benefit from the new predictor. I don't know if there is a good reason for this disparity...
Well in case somebody uses operator new:
int* p1 = new int;
we optimize out that to if (true), even when one has used defined
operator new. Thus it's probably OK.
Throwing new is returns_nonnull (errors are reported with exceptions) so
that's fine, but non-throwing new is not:
int* p1 = new(std::nothrow) int;
Here errors are reported by returning 0, so it is common to test if p1 is
0 and this is precisely the case that could benefit from a predictor but
does not have the attribute to do so (there are also consequences on
(Jan's remark about functions with an inferred malloc attribute reminds me
that at some point, the code was adding attribute malloc for functions
that always return 0...)