[llvm] r206429 - Inline a function when the always_inline attribute
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed Apr 16 22:54:35 PDT 2014
On 2014 Apr 16, at 17:51, Nick Lewycky <nlewycky at google.com> wrote:
> On 16 April 2014 17:21, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
> Author: ghoflehner
> Date: Wed Apr 16 19:21:52 2014
> New Revision: 206429
>
> URL: http://llvm.org/viewvc/llvm-project?rev=206429&view=rev
> Log:
> Inline a function when the always_inline attribute
> is set even when it contains a indirect branch.
> The attribute overrules correctness concerns
> like the escape of a local block address.
>
> False. Do not submit.
>
> If you want to inline functions that contain indirect branches, you need to teach the inliner how to do it correctly.
I agree with Eric and Nick. It seems like a dangerous semantic change
for the attribute, making previously correct code incorrect.
GCC docs for always_inline [1] (clang mentions it [2] twice [3] but
doesn't seem to define it) and LLVM LangRef.rst for alwaysinline [4]
indicate that the inlining thresholds should be ignored, but don't say
anything about the attribute trumping correctness.
[1]: http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html
[2]: http://clang.llvm.org/docs/LanguageExtensions.html
[3]: http://clang.llvm.org/docs/AttributeReference.html
[4]: http://llvm.org/docs/LangRef.html#function-attributes
> This has the added bonus that we'll then be able to inline regular functions with indirect branches too.
I'm not convinced this is a good idea anyway, unless our optimizations
are tuned for handling irreducible control flow. It seems likely that
keeping that logic sequestered is profitable.
More information about the llvm-commits
mailing list