[llvmlinux] Fwd: [PATCH] slab: Remove unnecessary __builtin_constant_p()

Behan Webster behanw at converseincode.com
Wed Apr 17 19:25:00 UTC 2013

Steve has submitted a patch to remove the __builtin_constant_p issue. :)


Sent from my Mobile Computer which is also a phone

Begin forwarded message:

*From:* Steven Rostedt <rostedt at goodmis.org>
*Date:* 17 April, 2013 12:09:36 PM PDT
*To:* LKML <linux-kernel at vger.kernel.org>, linux-mm at kvack.org
*Cc:* Christoph Lameter <cl at linux.com>, Behan Webster <
behanw at converseincode.com>,  Andrew Morton <akpm at linux-foundation.org>
*Subject:* *[PATCH] slab: Remove unnecessary __builtin_constant_p()*

The slab.c code has a size check macro that checks the size of the
following structs:

struct arraycache_init
struct kmem_list3

The index_of() function that takes the sizeof() of the above two structs
and does an unnecessary __builtin_constant_p() on that. As sizeof() will
always end up being a constant making this always be true. The code is
not incorrect, but it just adds added complexity, and confuses users and
wastes the time of reviewers of the code, who spends time trying to
figure out why the builtin_constant_p() was used.

This patch is just a clean up that makes the index_of() code a little
bit less complex.

Signed-off-by: Steven Rostedt <rostedt at goodmis.org>

diff --git a/mm/slab.c b/mm/slab.c
index 856e4a1..6047900 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -325,9 +325,7 @@ static void cache_reap(struct work_struct *unused);
static __always_inline int index_of(const size_t size)
   extern void __bad_size(void);
-    if (__builtin_constant_p(size)) {
-        int i = 0;
+    int i = 0;

#define CACHE(x) \
   if (size <=x) \
@@ -336,9 +334,7 @@ static __always_inline int index_of(const size_t size)
#include <linux/kmalloc_sizes.h>
#undef CACHE
-        __bad_size();
-    } else
-        __bad_size();
+    __bad_size();
   return 0;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130417/5ff005ff/attachment.html>

More information about the LLVMLinux mailing list