[COMMITTED] Remove explicit inline on malloc perturb functions.
diff mbox

Message ID 20141217184219.A76452C3AA0@topped-with-meat.com
State New
Headers show

Commit Message

Roland McGrath Dec. 17, 2014, 6:42 p.m. UTC
2014-12-17  Roland McGrath  <roland@hack.frob.com>

	* malloc/malloc.c (alloc_perturb, free_perturb): Remove inline keyword.

Comments

Ondřej Bílka Dec. 19, 2014, 4:06 p.m. UTC | #1
On Wed, Dec 17, 2014 at 10:42:19AM -0800, Roland McGrath wrote:
> 2014-12-17  Roland McGrath  <roland@hack.frob.com>
> 
> 	* malloc/malloc.c (alloc_perturb, free_perturb): Remove inline keyword.
> 
Roland, did you ran benchtest before commiting that?

You caused a 5% performance regression on malloc microbenchmark when
using gcc version 4.4.7 (Debian 4.4.7-8)
Ondřej Bílka Feb. 11, 2015, 2:01 p.m. UTC | #2
On Tue, Jan 13, 2015 at 02:58:06PM -0800, Roland McGrath wrote:
> > On Wed, Dec 17, 2014 at 10:42:19AM -0800, Roland McGrath wrote:
> > > 2014-12-17  Roland McGrath  <roland@hack.frob.com>
> > > 
> > > 	* malloc/malloc.c (alloc_perturb, free_perturb): Remove inline keyword.
> > > 
> > Roland, did you ran benchtest before commiting that?
> 
> No.  What I did verify is that on x86_64-linux-gnu with gcc 4.8.2 (Ubuntu
> 4.8.2-19ubuntu1), where the warning was not produced beforehand, it did
> not change the generated code.
> 
> > You caused a 5% performance regression on malloc microbenchmark when
> > using gcc version 4.4.7 (Debian 4.4.7-8)
> 
> I assume you're talking about x86_64-linux-gnu, but you should be
> clear when citing such things (in fact, you should probably say
> something about the hardware, since the results might be quite
> different even with the same compiler on different hardware).
> 
> That is older than the minimum required to build 2.21 (which is 4.6).
> Even if it were true with 4.6, I'm not convinced we should care.  It's
> always going to be the case that not all compiler vintages will
> produce good code from the same source.  We need to be able to move
> forward with cleanups and new best practices and not worry overmuch
> about building libc with compilers that are very old.  As of now, I'd
> say that anything that is suboptimal with a compiler older than 4.8
> but just fine with 4.8 or newer is something we should not be worrying
> about.
> 
No Roland, this does work only by chance, how can you know that gcc-5.2
 would decide not to inline these again? You cannot get always get correct 
decision without profile feedback which improves performance by 10% on
decisions like this.

Patch
diff mbox

--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -1854,14 +1854,14 @@  static int check_action = DEFAULT_CHECK_ACTION;
 
 static int perturb_byte;
 
-static inline void
+static void
 alloc_perturb (char *p, size_t n)
 {
   if (__glibc_unlikely (perturb_byte))
     memset (p, perturb_byte ^ 0xff, n);
 }
 
-static inline void
+static void
 free_perturb (char *p, size_t n)
 {
   if (__glibc_unlikely (perturb_byte))