From c30724e9a061135f8c7b925c0fcdf742510a3bc5 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Fri, 13 Sep 2019 00:19:24 +0200 Subject: compiler_types.h: don't #define __inline The spellings __inline and __inline__ should be reserved for uses where one really wants to refer to the inline keyword, regardless of whether or not the spelling "inline" has been #defined to something else. Due to use of __inline__ in uapi headers, we can't easily get rid of the definition of __inline__. However, almost all users of __inline have been converted to inline, so we can get rid of that #define. The exception is include/acpi/platform/acintel.h. However, that header is only included when using the intel compiler (does anybody actually build the kernel with that?), and the ACPI_INLINE macro is only used in the definition of utterly trivial stub functions, where I doubt a small change of semantics (lack of __gnu_inline) changes anything. Signed-off-by: Rasmus Villemoes [Fix trivial typo in message] Signed-off-by: Miguel Ojeda --- include/linux/compiler_types.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'include/linux/compiler_types.h') diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index 599c27b56c29..ee49be6d6088 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -150,8 +150,17 @@ struct ftrace_likely_data { __maybe_unused notrace #endif +/* + * gcc provides both __inline__ and __inline as alternate spellings of + * the inline keyword, though the latter is undocumented. New kernel + * code should only use the inline spelling, but some existing code + * uses __inline__. Since we #define inline above, to ensure + * __inline__ has the same semantics, we need this #define. + * + * However, the spelling __inline is strictly reserved for referring + * to the bare keyword. + */ #define __inline__ inline -#define __inline inline /* * Rather then using noinline to prevent stack consumption, use -- cgit From eb111869301e15b737315a46c913ae82bd19eb9d Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Fri, 13 Sep 2019 00:19:25 +0200 Subject: compiler-types.h: add asm_inline definition This adds an asm_inline macro which expands to "asm inline" [1] when the compiler supports it. This is currently gcc 9.1+, gcc 8.3 and (once released) gcc 7.5 [2]. It expands to just "asm" for other compilers. Using asm inline("foo") instead of asm("foo") overrules gcc's heuristic estimate of the size of the code represented by the asm() statement, and makes gcc use the minimum possible size instead. That can in turn affect gcc's inlining decisions. I wasn't sure whether to make this a function-like macro or not - this way, it can be combined with volatile as asm_inline volatile() but perhaps we'd prefer to spell that asm_inline_volatile() anyway. The Kconfig logic is taken from an RFC patch by Masahiro Yamada [3]. [1] Technically, asm __inline, since both inline and __inline__ are macros that attach various attributes, making gcc barf if one literally does "asm inline()". However, the third spelling __inline is available for referring to the bare keyword. [2] https://lore.kernel.org/lkml/20190907001411.GG9749@gate.crashing.org/ [3] https://lore.kernel.org/lkml/1544695154-15250-1-git-send-email-yamada.masahiro@socionext.com/ Signed-off-by: Rasmus Villemoes Signed-off-by: Miguel Ojeda --- include/linux/compiler_types.h | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'include/linux/compiler_types.h') diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index ee49be6d6088..2bf316fe0a20 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -198,6 +198,12 @@ struct ftrace_likely_data { #define asm_volatile_goto(x...) asm goto(x) #endif +#ifdef CONFIG_CC_HAS_ASM_INLINE +#define asm_inline asm __inline +#else +#define asm_inline asm +#endif + #ifndef __no_fgcse # define __no_fgcse #endif -- cgit