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
next prev parent 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).