Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1670678 > unrolled thread

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

Started byMark Rutland <mark.rutland@arm.com>
First post2017-06-20 13:10 +0200
Last post2017-06-23 08:50 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] compiler, clang: Add always_inline attribute to inline Mark Rutland <mark.rutland@arm.com> - 2017-06-20 13:10 +0200
    Re: [PATCH] compiler, clang: Add always_inline attribute to inline David Rientjes <rientjes@google.com> - 2017-06-21 01:20 +0200
      Re: [PATCH] compiler, clang: Add always_inline attribute to inline Mark Rutland <mark.rutland@arm.com> - 2017-06-22 11:50 +0200
        Re: [PATCH] compiler, clang: Add always_inline attribute to inline Sodagudi Prasad <psodagud@codeaurora.org> - 2017-06-23 08:50 +0200

#1670678 — Re: [PATCH] compiler, clang: Add always_inline attribute to inline

FromMark Rutland <mark.rutland@arm.com>
Date2017-06-20 13:10 +0200
SubjectRe: [PATCH] compiler, clang: Add always_inline attribute to inline
Message-ID<tUpcK-7R1-29@gated-at.bofh.it>
On Mon, Jun 19, 2017 at 03:19:27PM -0700, Sodagudi Prasad wrote:
> On 2017-06-19 14:42, David Rientjes wrote:
> >Yes, the arch/arm64/include/asm/cmpxchg.h instance appears to need
> >__always_inline as several other functions need __always_inline in
> >arch/arm64/include/*.  It's worth making that change as you
> >suggested in
> >your original patch.
> >
> >The concern, however, is inlining all "inline" functions
> >forcefully.  The
> >only reason this is done for gcc is because of suboptimal inlining
> >decisions in gcc < 4.
> >
> >So the question is whether this is a single instance that can be fixed
> >where clang un-inlining causes problems or whether that instance
> >suggests
> >all possible inline usage for clang absolutely requires __always_inline
> >due to a suboptimal compiler implementation.  I would suggest the
> >former.
> 
> Hi David,
> 
>  I am not 100% sure about the best approach for this problem. We may
> have to
> replace inline with always_inline for all inline functions where
> BUILD_BUG() used.
> 
> So far inline as always_inline for ARM64, if we do not continue same
> settings,
> will there not be any performance differences?
> 
> Hi Will and Mark,
> 
> Please suggest the best solution to this problem. Currently
> __xchg_mb is only having issue
> based on compiler -inline-threshold configuration. But there are
> many other instances
> in arch/arm64/* where BUILD_BUG() used for inline functions and
> which may fail later.

As with my reply to David, my preference would be that we:

1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so
   that things work by default.

2) Fix up the arm64 core code (and drivers for architected / common
   peripherals) to use __always_inline where we always require inlining.

3) Have arm64 select CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING, and have
   people test-build configurations with CONFIG_OPTIMIZE_INLINING, with
   both GCC and clang.

4) Fix up drivers, etc, as appropriate.

5) Once that's largely stable, and if there's a benefit, have arm64
   select CONFIG_OPTIMIZE_INLINING by default.

That should avoid undue breakage, while enabling this ASAP.

Thanks,
Mark.

[toc] | [next] | [standalone]


#1671225

FromDavid Rientjes <rientjes@google.com>
Date2017-06-21 01:20 +0200
Message-ID<tUABc-6zP-25@gated-at.bofh.it>
In reply to#1670678
On Tue, 20 Jun 2017, Mark Rutland wrote:

> As with my reply to David, my preference would be that we:
> 
> 1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so
>    that things work by default.
> 
> 2) Fix up the arm64 core code (and drivers for architected / common
>    peripherals) to use __always_inline where we always require inlining.
> 
> 3) Have arm64 select CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING, and have
>    people test-build configurations with CONFIG_OPTIMIZE_INLINING, with
>    both GCC and clang.
> 
> 4) Fix up drivers, etc, as appropriate.
> 
> 5) Once that's largely stable, and if there's a benefit, have arm64
>    select CONFIG_OPTIMIZE_INLINING by default.
> 
> That should avoid undue breakage, while enabling this ASAP.
> 

Sounds good, but I think we should simply deal with the 
__attribute__((unused)) needed for clang as part of compiler-gcc.h by 
simply adding it to the inline override there to avoid duplicated code.

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -15,11 +15,3 @@
  * with any version that can compile the kernel
  */
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-
-/*
- * GCC does not warn about unused static inline functions for
- * -Wunused-function.  This turns out to avoid the need for complex #ifdef
- * directives.  Suppress the warning in clang as well.
- */
-#undef inline
-#define inline inline __attribute__((unused)) notrace
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 0efef9cf014f..71fe0994cf1a 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -66,18 +66,22 @@
 
 /*
  * Force always-inline if the user requests it so via the .config,
- * or if gcc is too old:
+ * or if gcc is too old.
+ * GCC does not warn about unused static inline functions for
+ * -Wunused-function.  This turns out to avoid the need for complex #ifdef
+ * directives.  Suppress the warning in clang as well by using "unused"
+ * function attribute, which is redundant but not harmful for gcc.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||		\
     !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline		inline		__attribute__((always_inline)) notrace
-#define __inline__	__inline__	__attribute__((always_inline)) notrace
-#define __inline	__inline	__attribute__((always_inline)) notrace
+#define inline inline		__attribute__((always_inline,unused)) notrace
+#define __inline__ __inline__	__attribute__((always_inline,unused)) notrace
+#define __inline __inline	__attribute__((always_inline,unused)) notrace
 #else
 /* A lot of inline functions can cause havoc with function tracing */
-#define inline		inline		notrace
-#define __inline__	__inline__	notrace
-#define __inline	__inline	notrace
+#define inline inline		__attribute__((unused)) notrace
+#define __inline__ __inline__	__attribute__((unused)) notrace
+#define __inline __inline	__attribute__((unused)) notrace
 #endif
 
 #define __always_inline	inline __attribute__((always_inline))

[toc] | [prev] | [next] | [standalone]


#1672478

FromMark Rutland <mark.rutland@arm.com>
Date2017-06-22 11:50 +0200
Message-ID<tV6Uq-2Rl-19@gated-at.bofh.it>
In reply to#1671225
On Tue, Jun 20, 2017 at 04:12:32PM -0700, David Rientjes wrote:
> On Tue, 20 Jun 2017, Mark Rutland wrote:
> 
> > As with my reply to David, my preference would be that we:
> > 
> > 1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so
> >    that things work by default.
> > 
> > 2) Fix up the arm64 core code (and drivers for architected / common
> >    peripherals) to use __always_inline where we always require inlining.
> > 
> > 3) Have arm64 select CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING, and have
> >    people test-build configurations with CONFIG_OPTIMIZE_INLINING, with
> >    both GCC and clang.
> > 
> > 4) Fix up drivers, etc, as appropriate.
> > 
> > 5) Once that's largely stable, and if there's a benefit, have arm64
> >    select CONFIG_OPTIMIZE_INLINING by default.
> > 
> > That should avoid undue breakage, while enabling this ASAP.
> > 
> 
> Sounds good, but I think we should simply deal with the 
> __attribute__((unused)) needed for clang as part of compiler-gcc.h by 
> simply adding it to the inline override there to avoid duplicated code.

Agreed. That looks much better.

Thanks,
Mark.

> 
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -15,11 +15,3 @@
>   * with any version that can compile the kernel
>   */
>  #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
> -
> -/*
> - * GCC does not warn about unused static inline functions for
> - * -Wunused-function.  This turns out to avoid the need for complex #ifdef
> - * directives.  Suppress the warning in clang as well.
> - */
> -#undef inline
> -#define inline inline __attribute__((unused)) notrace
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 0efef9cf014f..71fe0994cf1a 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -66,18 +66,22 @@
>  
>  /*
>   * Force always-inline if the user requests it so via the .config,
> - * or if gcc is too old:
> + * or if gcc is too old.
> + * GCC does not warn about unused static inline functions for
> + * -Wunused-function.  This turns out to avoid the need for complex #ifdef
> + * directives.  Suppress the warning in clang as well by using "unused"
> + * function attribute, which is redundant but not harmful for gcc.
>   */
>  #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||		\
>      !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
> -#define inline		inline		__attribute__((always_inline)) notrace
> -#define __inline__	__inline__	__attribute__((always_inline)) notrace
> -#define __inline	__inline	__attribute__((always_inline)) notrace
> +#define inline inline		__attribute__((always_inline,unused)) notrace
> +#define __inline__ __inline__	__attribute__((always_inline,unused)) notrace
> +#define __inline __inline	__attribute__((always_inline,unused)) notrace
>  #else
>  /* A lot of inline functions can cause havoc with function tracing */
> -#define inline		inline		notrace
> -#define __inline__	__inline__	notrace
> -#define __inline	__inline	notrace
> +#define inline inline		__attribute__((unused)) notrace
> +#define __inline__ __inline__	__attribute__((unused)) notrace
> +#define __inline __inline	__attribute__((unused)) notrace
>  #endif
>  
>  #define __always_inline	inline __attribute__((always_inline))

[toc] | [prev] | [next] | [standalone]


#1673294

FromSodagudi Prasad <psodagud@codeaurora.org>
Date2017-06-23 08:50 +0200
Message-ID<tVqzL-78A-1@gated-at.bofh.it>
In reply to#1672478
On 2017-06-22 02:43, Mark Rutland wrote:
> On Tue, Jun 20, 2017 at 04:12:32PM -0700, David Rientjes wrote:
>> On Tue, 20 Jun 2017, Mark Rutland wrote:
>> 
>> > As with my reply to David, my preference would be that we:
>> >
>> > 1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so
>> >    that things work by default.
>> >
>> > 2) Fix up the arm64 core code (and drivers for architected / common
>> >    peripherals) to use __always_inline where we always require inlining.
>> >
>> > 3) Have arm64 select CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING, and have
>> >    people test-build configurations with CONFIG_OPTIMIZE_INLINING, with
>> >    both GCC and clang.
>> >
>> > 4) Fix up drivers, etc, as appropriate.
>> >
>> > 5) Once that's largely stable, and if there's a benefit, have arm64
>> >    select CONFIG_OPTIMIZE_INLINING by default.
>> >
>> > That should avoid undue breakage, while enabling this ASAP.
>> >
>> 
>> Sounds good, but I think we should simply deal with the
>> __attribute__((unused)) needed for clang as part of compiler-gcc.h by
>> simply adding it to the inline override there to avoid duplicated 
>> code.
> 
> Agreed. That looks much better.
> 
> Thanks,
> Mark.
> 
>> 
>> diff --git a/include/linux/compiler-clang.h 
>> b/include/linux/compiler-clang.h
>> --- a/include/linux/compiler-clang.h
>> +++ b/include/linux/compiler-clang.h
>> @@ -15,11 +15,3 @@
>>   * with any version that can compile the kernel
>>   */
>>  #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), 
>> __COUNTER__)
>> -
>> -/*
>> - * GCC does not warn about unused static inline functions for
>> - * -Wunused-function.  This turns out to avoid the need for complex 
>> #ifdef
>> - * directives.  Suppress the warning in clang as well.
>> - */
>> -#undef inline
>> -#define inline inline __attribute__((unused)) notrace
>> diff --git a/include/linux/compiler-gcc.h 
>> b/include/linux/compiler-gcc.h
>> index 0efef9cf014f..71fe0994cf1a 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -66,18 +66,22 @@
>> 
>>  /*
>>   * Force always-inline if the user requests it so via the .config,
>> - * or if gcc is too old:
>> + * or if gcc is too old.
>> + * GCC does not warn about unused static inline functions for
>> + * -Wunused-function.  This turns out to avoid the need for complex 
>> #ifdef
>> + * directives.  Suppress the warning in clang as well by using 
>> "unused"
>> + * function attribute, which is redundant but not harmful for gcc.
>>   */
>>  #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||		\
>>      !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
>> -#define inline		inline		__attribute__((always_inline)) notrace
>> -#define __inline__	__inline__	__attribute__((always_inline)) notrace
>> -#define __inline	__inline	__attribute__((always_inline)) notrace
>> +#define inline inline		__attribute__((always_inline,unused)) notrace
>> +#define __inline__ __inline__	__attribute__((always_inline,unused)) 
>> notrace
>> +#define __inline __inline	__attribute__((always_inline,unused)) 
>> notrace
>>  #else
>>  /* A lot of inline functions can cause havoc with function tracing */
>> -#define inline		inline		notrace
>> -#define __inline__	__inline__	notrace
>> -#define __inline	__inline	notrace
>> +#define inline inline		__attribute__((unused)) notrace
>> +#define __inline__ __inline__	__attribute__((unused)) notrace
>> +#define __inline __inline	__attribute__((unused)) notrace
>>  #endif
>> 
>>  #define __always_inline	inline __attribute__((always_inline))
Hi David,

I just want to cross check with you.
Do you want me to update this change in next patch set ? Or are you 
going to add this ?

-Thanks, Prasad
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
Linux Foundation Collaborative Project

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web