<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 10:54 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> False. Do not submit.<br>
><br>
> If you want to inline functions that contain indirect branches, you need to teach the inliner how to do it correctly.<br>
<br>
</div>I agree with Eric and Nick.  It seems like a dangerous semantic change<br>
for the attribute, making previously correct code incorrect.<br>
<br>
GCC docs for always_inline [1] (clang mentions it [2] twice [3] but<br>
doesn't seem to define it) and LLVM LangRef.rst for alwaysinline [4]<br>
indicate that the inlining thresholds should be ignored, but don't say<br>
anything about the attribute trumping correctness.<br>
<br>
[1]: <a href="http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html" target="_blank">http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html</a><br>
[2]: <a href="http://clang.llvm.org/docs/LanguageExtensions.html" target="_blank">http://clang.llvm.org/docs/LanguageExtensions.html</a><br>
[3]: <a href="http://clang.llvm.org/docs/AttributeReference.html" target="_blank">http://clang.llvm.org/docs/AttributeReference.html</a><br>
[4]: <a href="http://llvm.org/docs/LangRef.html#function-attributes" target="_blank">http://llvm.org/docs/LangRef.html#function-attributes</a></blockquote><div><br></div><div>As the last person to deal with this, I can confidently say that it does *not* trump correctness. I hit many, many cases where it was absolutely critical that it apply in all cases except those which it cannot apply under.</div>
<div><br></div><div>At most, we should error in the frontend whenever we can trivially show that always_inline is incompatible with the function, but that is totally different from inlining blindly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<div class=""><br>
> This has the added bonus that we'll then be able to inline regular functions with indirect branches too.<br>
<br>
</div>I'm not convinced this is a good idea anyway, unless our optimizations<br>
are tuned for handling irreducible control flow.  It seems likely that<br>
keeping that logic sequestered is profitable.</blockquote></div><br>I think this is a good idea for one simple reason: inlining is one of the only things that has a decent chance at constant folding away the indirectbr or DCE-ing it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I don't think we need to worry much about getting the thresholds right here. The way the current inliner works it will never do this except for tiny indirectbr usages, or cases where some or all of the indirectbr reached blocks are DCE-ed.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>