From patchwork Tue Sep 25 23:30:46 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Santos X-Patchwork-Id: 1506831 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 699D7DFE80 for ; Tue, 25 Sep 2012 23:30:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754912Ab2IYXay (ORCPT ); Tue, 25 Sep 2012 19:30:54 -0400 Received: from nm26.bullet.mail.sp2.yahoo.com ([98.139.91.96]:38522 "HELO nm26.bullet.mail.sp2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754682Ab2IYXax (ORCPT ); Tue, 25 Sep 2012 19:30:53 -0400 Received: from [72.30.22.77] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 25 Sep 2012 23:30:52 -0000 Received: from [98.139.44.93] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 25 Sep 2012 23:30:52 -0000 Received: from [127.0.0.1] by omp1030.access.mail.sp2.yahoo.com with NNFMP; 25 Sep 2012 23:30:52 -0000 X-Yahoo-Newman-Id: 898427.90796.bm@omp1030.access.mail.sp2.yahoo.com Received: (qmail 29687 invoked from network); 25 Sep 2012 23:30:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348615852; bh=+VvGO36ropq288mL891jYLSxOykrgx7qzMaYwAvNOAI=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References; b=IITBiSKR5QyUxCtw9+qysp/whiczawBDsF4pGkR3a8f7T9pOe5QgI2Uezw6B+UFjACO7hJ3zVxC6VsPcGvRg9PGEgpy82G8AxLC1EGj8ujZcIHEgjWEyIqUmAMsJSQnGsIAar/ABE/9jhFWhYLYT5olQFnDbUe30S2PPH+9q6Sw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZsdWBc8VM1l7NZ9gUWc_UbBEZccTuLw_cLnaTGOQl9iqKF1 8avmnLKMZfF3xBNfYTUE5XBCqAHBYLizpCXN5qcfD0PId5MCiVP6l0CZpML0 Yoim1bT0kUt0JNo2_r9WQYh_j0i2FVXOhUkWuW30ET0w1eV0ZJ8IdMQBjFAT ObiLRmmMnwd5eOMcBJAcPdfmcI4e0biNvBOkbD_.mij6wtGYpUVFbKv7k24a ZtorrO30pv0cRl9S4N7HEB533yAf...0Cr3jD39_6F5gsdTrHFq.Nkc77iNB DEjcKYs1l0rD41fJWXH.VBIkR5yae8nLa.hXtBpPFABZdnAxd4pCAQ07GUoP cFG.Bb0i._M0TRjuuQnePeftu24AMbgc9OgWX9Kch8oTPPBJlkRqvuqcaXpn bYcie1.kEr10fG9OIaPIYIQ8DnTd9bzUIBvEQgnW1VbHoYQ41qoDxB0s6lDg xBQWj954OjBnSFNWjgJo6_hRQ2guhIViwBBeNz6_.EYOK7JexznXWeN29sch MZ2..lGYi6n531Igx9OjpWYpe2isRu_Ko_dc- X-Yahoo-SMTP: xXkkXk6swBBAi.5wfkIWFW3ugxbrqyhyk_b4Z25Sfu.XGQ-- Received: from localhost.localdomain (danielfsantos@99.70.244.137 with login) by smtp106.sbc.mail.ne1.yahoo.com with SMTP; 25 Sep 2012 16:30:52 -0700 PDT From: Daniel Santos To: Christopher Li , Daniel Santos , Andrew Morton , David Howells , David Daney , David Rientjes , linux-sparse@vger.kernel.org, Pavel Pisa , Richard Weinberger , LKML , Michel Lespinasse , Andrea Arcangeli , Peter Zijlstra , Rik van Riel Subject: [PATCH v5 7/25] compiler{, -gcc4}.h: Introduce __flatten function attribute Date: Tue, 25 Sep 2012 18:30:46 -0500 Message-Id: <1348615846-10193-1-git-send-email-daniel.santos@pobox.com> X-Mailer: git-send-email 1.7.3.4 In-Reply-To: <1348615467-9850-1-git-send-email-daniel.santos@pobox.com> References: <1348615467-9850-1-git-send-email-daniel.santos@pobox.com> Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org For gcc 4.1 & later, expands to __attribute__((flatten)) which forces the compiler to inline everything it can into the function. This is useful in combination with noinline when you want to control the depth of inlining, or create a single function where inline expansions will occur. (see http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bflatten_007d-function-attribute-2512) Normally, it's best to leave this type of thing up to the compiler. However, the generic rbtree code uses inline functions just to be able to inject compile-time constant data that specifies how the caller wants the function to behave (via struct rb_relationship). This data can be thought of as the template parameters of a C++ templatized function. Since some of these functions, once expanded, become quite large, gcc sometimes decides not to perform some important inlining, in one case, even generating a few bytes more code by not doing so. (Note: I have not eliminated the possibility that this was an optimization bug, but the flatten attribute fixes it in either case.) Combining __flatten and noinline insures that important optimizations occur in these cases and that the inline expansion occurs in exactly one place, thus not leading to unnecissary bloat. However, it also can eliminate some opportunities for optimization should gcc otherwise decide the function its self is a good candidate for inlining. Signed-off-by: Daniel Santos --- include/linux/compiler-gcc4.h | 7 ++++++- include/linux/compiler.h | 4 ++++ 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 5755e23..38fb81d 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -15,7 +15,12 @@ #if GCC_VERSION >= 40102 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) -#endif + +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/ +# if GCC_VERSION != 40600 +# define __flatten __attribute__((flatten)) +# endif +#endif /* GCC_VERSION >= 40102 */ #if GCC_VERSION >= 40300 /* Mark functions as cold. gcc will assume any path leading to a call diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 4d9f353..b26d606 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -244,6 +244,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); #define __always_inline inline #endif +#ifndef __flatten +#define __flatten +#endif + #endif /* __KERNEL__ */ /*