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
WARNING: multiple messages have this Message-ID (diff)
From: Sodagudi Prasad <psodagud@codeaurora.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: David Rientjes <rientjes@google.com>,
will.deacon@arm.com, catalin.marinas@arm.com, mingo@kernel.org,
peterz@infradead.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [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
next prev parent reply other threads:[~2017-06-23 6:45 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
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 [this message]
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=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 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.