All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.