From: psodagud@codeaurora.org (Sodagudi Prasad)
To: linux-arm-kernel@lists.infradead.org
Subject: Using __always_inline attribute
Date: Wed, 14 Jun 2017 17:50:26 -0700 [thread overview]
Message-ID: <e77e6745b60629315b1b4f0e4fddd4bf@codeaurora.org> (raw)
In-Reply-To: <9198053a46999b0b46dcab992527d0d7@codeaurora.org>
On 2017-06-14 15:33, Sodagudi Prasad wrote:
> On 2017-06-14 03:06, Will Deacon wrote:
>> Hi Prasad,
>>
>> On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote:
>>> With a variant of a CLANG(based on 4.0) following errors observed on
>>> Linux
>>> 4.12-rc5 tag.
>>
>> How are you building the kernel with clang, btw? I'd be keen to try
>> the same
>> thing, but I thought the LLVMLinux project was largely dead at his
>> point. Do
>> you still need build system patches, or is this now integrated with
>> Kbuild?
> Hi Will,
> Trying clang patches from below tree -
> https://android.googlesource.com/kernel/common/+/experimental/android-4.4-llvm
>
>>
>>> net/built-in.o: In function `__xchg_mb':
>>> arch/arm64/include/asm/cmpxchg.h:99: \
>>> undefined reference to `__compiletime_assert_99'
>>> arch/arm64/include/asm/cmpxchg.h:99: \
>>> undefined reference to `__compiletime_assert_99
>>>
>>> Clang does not seems to be marking this macro as inline and causing
>>> above
>>> compilation issue due to BUILD_BUG().
>>
>> The only BUILD_BUG I see around here is if the size parameter (which
>> is
>> calculated using sizeof) is not known to be 1,2,4 or 8 at compile
>> time. It
>> would be interesting to know which call site is confusing clang in
>> this way
>> and what code is actually being emitted here.
>>
>> If it's just that __xchg_mb isn't being inlined into the
>> __xchg_wrapper
>> macro, then your patch should be ok, but I'd like to be sure it's not
>> something else. I'm also surprised you haven't see this crop up in
>> other
>> places.
> After digging further, we observed that inline definition was changed
> recently and causing this issue.
> Here is missing part of inline macro definition
> __attribute__((unused)).
>
> Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
> static inline functions") have redefined the inline macro as below
> #define inline inline __attribute__((unused))
>
> But actual definition of inline macro defined compiler-gcc.h file as
> shown below.
> #define inline inline __attribute__((always_inline))
> notrace
>
> As always_inline attribute is missing in inline definition, compile
> may not inline macros __xchg_mb in
> arch/arm64/include/asm/cmpxchg.h file and leading to error.
>
> Some compilers may not honor inline as inline if always_inline
> attribute is removed because of
> -inline-threshold compiler options.
>
> Here is the change to fix this issue-
> diff --git a/include/linux/compiler-clang.h
> b/include/linux/compiler-clang.h
> index d614c5e..a0e6433 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -22,4 +22,4 @@
> * directives. Suppress the warning in clang as well.
> */
> #undef inline
> -#define inline inline __attribute__((unused)) notrace
> +#define inline __attribute__((always_inline)) __attribute__((unused))
> notrace
>
> -Thanks, Prasad
Hi Will,
Here is the proper patch -
compiler, clang: Add always_inline attribute to inline
Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
static inline functions") re-defining the 'inline' macro but
__attribute__((always_inline)) is missing. Some compilers may
not honor inline hint if always_iniline attribute is not there.
So add always_inline attribute to inline as done by
compiler-gcc.h file.
diff --git a/include/linux/compiler-clang.h
b/include/linux/compiler-clang.h
index d614c5e..400b0cd 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -22,4 +22,4 @@
* directives. Suppress the warning in clang as well.
*/
#undef inline
-#define inline inline __attribute__((unused)) notrace
+#define inline inline __attribute__((always_inline))
__attribute__((unused)) notrace
-Thanks, Prasad
>>
>> Will
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: Sodagudi Prasad <psodagud@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>
Cc: catalin.marinas@arm.com, mingo@kernel.org, peterz@infradead.org,
mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: Using __always_inline attribute
Date: Wed, 14 Jun 2017 17:50:26 -0700 [thread overview]
Message-ID: <e77e6745b60629315b1b4f0e4fddd4bf@codeaurora.org> (raw)
In-Reply-To: <9198053a46999b0b46dcab992527d0d7@codeaurora.org>
On 2017-06-14 15:33, Sodagudi Prasad wrote:
> On 2017-06-14 03:06, Will Deacon wrote:
>> Hi Prasad,
>>
>> On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote:
>>> With a variant of a CLANG(based on 4.0) following errors observed on
>>> Linux
>>> 4.12-rc5 tag.
>>
>> How are you building the kernel with clang, btw? I'd be keen to try
>> the same
>> thing, but I thought the LLVMLinux project was largely dead at his
>> point. Do
>> you still need build system patches, or is this now integrated with
>> Kbuild?
> Hi Will,
> Trying clang patches from below tree -
> https://android.googlesource.com/kernel/common/+/experimental/android-4.4-llvm
>
>>
>>> net/built-in.o: In function `__xchg_mb':
>>> arch/arm64/include/asm/cmpxchg.h:99: \
>>> undefined reference to `__compiletime_assert_99'
>>> arch/arm64/include/asm/cmpxchg.h:99: \
>>> undefined reference to `__compiletime_assert_99
>>>
>>> Clang does not seems to be marking this macro as inline and causing
>>> above
>>> compilation issue due to BUILD_BUG().
>>
>> The only BUILD_BUG I see around here is if the size parameter (which
>> is
>> calculated using sizeof) is not known to be 1,2,4 or 8 at compile
>> time. It
>> would be interesting to know which call site is confusing clang in
>> this way
>> and what code is actually being emitted here.
>>
>> If it's just that __xchg_mb isn't being inlined into the
>> __xchg_wrapper
>> macro, then your patch should be ok, but I'd like to be sure it's not
>> something else. I'm also surprised you haven't see this crop up in
>> other
>> places.
> After digging further, we observed that inline definition was changed
> recently and causing this issue.
> Here is missing part of inline macro definition
> __attribute__((unused)).
>
> Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
> static inline functions") have redefined the inline macro as below
> #define inline inline __attribute__((unused))
>
> But actual definition of inline macro defined compiler-gcc.h file as
> shown below.
> #define inline inline __attribute__((always_inline))
> notrace
>
> As always_inline attribute is missing in inline definition, compile
> may not inline macros __xchg_mb in
> arch/arm64/include/asm/cmpxchg.h file and leading to error.
>
> Some compilers may not honor inline as inline if always_inline
> attribute is removed because of
> -inline-threshold compiler options.
>
> Here is the change to fix this issue-
> diff --git a/include/linux/compiler-clang.h
> b/include/linux/compiler-clang.h
> index d614c5e..a0e6433 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -22,4 +22,4 @@
> * directives. Suppress the warning in clang as well.
> */
> #undef inline
> -#define inline inline __attribute__((unused)) notrace
> +#define inline __attribute__((always_inline)) __attribute__((unused))
> notrace
>
> -Thanks, Prasad
Hi Will,
Here is the proper patch -
compiler, clang: Add always_inline attribute to inline
Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
static inline functions") re-defining the 'inline' macro but
__attribute__((always_inline)) is missing. Some compilers may
not honor inline hint if always_iniline attribute is not there.
So add always_inline attribute to inline as done by
compiler-gcc.h file.
diff --git a/include/linux/compiler-clang.h
b/include/linux/compiler-clang.h
index d614c5e..400b0cd 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -22,4 +22,4 @@
* directives. Suppress the warning in clang as well.
*/
#undef inline
-#define inline inline __attribute__((unused)) notrace
+#define inline inline __attribute__((always_inline))
__attribute__((unused)) notrace
-Thanks, Prasad
>>
>> Will
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-06-15 0:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-13 22:39 Using __always_inline attribute Sodagudi Prasad
2017-06-13 22:39 ` Sodagudi Prasad
2017-06-14 10:06 ` Will Deacon
2017-06-14 10:06 ` Will Deacon
2017-06-14 22:33 ` Sodagudi Prasad
2017-06-14 22:33 ` Sodagudi Prasad
2017-06-15 0:50 ` Sodagudi Prasad [this message]
2017-06-15 0:50 ` Sodagudi Prasad
2017-06-15 15:54 ` Mark Rutland
2017-06-15 15:54 ` Mark Rutland
2017-06-19 15:53 ` [PATCH] compiler, clang: Add always_inline attribute to inline Prasad Sodagudi
2017-06-19 15:53 ` Prasad Sodagudi
2017-06-19 20:25 ` David Rientjes
2017-06-19 20:25 ` David Rientjes
2017-06-19 21:14 ` Sodagudi Prasad
2017-06-19 21:14 ` Sodagudi Prasad
2017-06-19 21:42 ` David Rientjes
2017-06-19 21:42 ` David Rientjes
2017-06-19 22:19 ` Sodagudi Prasad
2017-06-19 22:19 ` Sodagudi Prasad
2017-06-20 10:59 ` Mark Rutland
2017-06-20 10:59 ` Mark Rutland
2017-06-20 23:12 ` David Rientjes
2017-06-20 23:12 ` David Rientjes
2017-06-22 9:43 ` Mark Rutland
2017-06-22 9:43 ` Mark Rutland
2017-06-23 6:45 ` Sodagudi Prasad
2017-06-23 6:45 ` Sodagudi Prasad
2017-06-20 10:52 ` Mark Rutland
2017-06-20 10:52 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e77e6745b60629315b1b4f0e4fddd4bf@codeaurora.org \
--to=psodagud@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.