linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: psodagud@codeaurora.org (Sodagudi Prasad)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] compiler, clang: Add always_inline attribute to inline
Date: Thu, 22 Jun 2017 23:45:26 -0700	[thread overview]
Message-ID: <c7d4238fe66c663081fcbdb74a839f3e@codeaurora.org> (raw)
In-Reply-To: <20170622094333.GB25967@leverpostej>

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

  reply	other threads:[~2017-06-23  6:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-13 22:39 Using __always_inline attribute Sodagudi Prasad
2017-06-14 10:06 ` Will Deacon
2017-06-14 22:33   ` Sodagudi Prasad
2017-06-15  0:50     ` Sodagudi Prasad
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 20:25         ` David Rientjes
2017-06-19 21:14           ` Sodagudi Prasad
2017-06-19 21:42             ` David Rientjes
2017-06-19 22:19               ` Sodagudi Prasad
2017-06-20 10:59                 ` Mark Rutland
2017-06-20 23:12                   ` David Rientjes
2017-06-22  9:43                     ` Mark Rutland
2017-06-23  6:45                       ` Sodagudi Prasad [this message]
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=c7d4238fe66c663081fcbdb74a839f3e@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).