[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