From patchwork Fri Sep 28 23:20:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Santos X-Patchwork-Id: 1527521 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 58E4D40D90 for ; Fri, 28 Sep 2012 23:21:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964799Ab2I1XVp (ORCPT ); Fri, 28 Sep 2012 19:21:45 -0400 Received: from nm22-vm0.bullet.mail.sp2.yahoo.com ([98.139.91.222]:40584 "HELO nm22-vm0.bullet.mail.sp2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1759124Ab2I1XVl (ORCPT ); Fri, 28 Sep 2012 19:21:41 -0400 Received: from [98.139.91.63] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 28 Sep 2012 23:21:41 -0000 Received: from [66.94.237.120] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 28 Sep 2012 23:21:40 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 28 Sep 2012 23:21:40 -0000 X-Yahoo-Newman-Id: 852307.56631.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 81407 invoked from network); 28 Sep 2012 23:21:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348874500; bh=5QfY3BnT/+AETPiU010LK6fM8yKRoYmM5bka6TAMFhE=; 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=1LbTkMWcFOyouD7G2C+JbO5DU9j2wIlzOZtyokZpvgGIRZY9lJeZRZA85sUHO7duMb0ziwJT5QqKQjs3b5WTdNYJ0yR5sPtZF4zHsMMxP+6KpK6Zrn/B9kala4gmZgkjui+qmnI9MnBeKDcB8k/yufxaK8vcHfe4Z77X9/KiDYY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GH0GOEUVM1k7Zp2eCzm94lg1V.cTJcX1Ac5Njjwr7gqp6Uj zcSu4eZH4.1nuicyfeHTYtQQBf4GBJSqz_IsWoJALu6aMo6f0UTwh.fB1JvX 3rxBytkKfmHD2gG1niveczrkYgrxpicGuwSnraXEOfDRB3hTtLTZSkjxzoFU FuZIEG0RYnpiOw1rd3HMOd1xCV6YL1OBuKr8WFa9ohDlDdlLc4q8gM4hBn5i VHTl7Bp1kFpmdciIUayYJ_D4HuTfRDEay3hngKw8SKiwFjdy5dViju1cqCxE qoEXNfar4.Ucyy6_m6nUAGycnGY7Zti4OI.sxR2ZFPyiyMcZ1B76M8Xrkw6q o3VtI39VCRRysRoxSH7deGqu_A196YGua2L4uQuUD808zbC349HyR4qlOMfb wBPQn8CL72NrTNiwc_POxoqUo5KzQJ56SWxMBAm8sNi0f_s9iUK..Mhlr_3a PLtxEl1IZVf9hWAGPeMv.6sP1GiPCdpsU3dXlHIXh7c7vEGnRPMGsTIsxhR3 A4nnIAfjKEXbKv6hETLEzNvA4MjTlidT7w_b6 X-Yahoo-SMTP: xXkkXk6swBBAi.5wfkIWFW3ugxbrqyhyk_b4Z25Sfu.XGQ-- Received: from localhost.localdomain (danielfsantos@99.70.244.137 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2012 23:21:40 +0000 UTC From: Daniel Santos To: LKML , Andi Kleen , Andrea Arcangeli , Andrew Morton , Christopher Li , Daniel Santos , David Daney , David Howells , Joe Perches , Konstantin Khlebnikov , linux-sparse@vger.kernel.org, Michel Lespinasse , Paul Gortmaker , Pavel Pisa , Peter Zijlstra , Steven Rostedt Subject: [PATCH 7/10] compiler{, -gcc4}.h: Introduce __flatten function attribute Date: Fri, 28 Sep 2012 18:20:08 -0500 Message-Id: <1348874411-28288-8-git-send-email-daniel.santos@pobox.com> X-Mailer: git-send-email 1.7.3.4 In-Reply-To: <1348874411-28288-1-git-send-email-daniel.santos@pobox.com> References: <1348874411-28288-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 ad610f2..5a0897e 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 fd455aa..268aeb6 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__ */ /*