[LLVMdev] Inline hint for methods defined in-class (original) (raw)

Krzysztof Parzyszek kparzysz at codeaurora.org
Wed Jul 8 14:40:24 PDT 2015

On 7/7/2015 8:06 PM, Chandler Carruth wrote:

I think that tying any optimizer behavior to the 'inline' keyword is fundamentally the wrong direction. We have reasons why we have done this historically, and we can't just do an immediate about face, but we should be actively looking for ways to reduce the optimizer's reliance on this keyword to convey any meaning whatsoever.

When it comes to performance, it is often the case that tuning the inliner can produce measurable benefits. The problem is though, that these tweaks will likely degrade other applications. I don't believe that the compiler's analysis of the code will ever be sufficient to adequately meet everyone's needs. For now, the "inline" keyword is used as a hint that the programmer can provide to the compiler. If we move away from paying any attention to "inline", we should keep in place another mechanism to allow the programmer to influence the inliner's decisions.

The reason I think that is the correct direction is because, for better or worse, the 'inline' keyword in C++ is not about optimization, but about linkage. It has a functional impact and can be both necessary or impossible to use to meet those functional requirements. This in turn leaves programmers in a lurch if the functional requirements are ever in tension with the optimizer requirements.

Could you give an example of such a situation? The "inline" keyword in C has some unintuitive consequences (i.e. not provinding an "external definition"), but since C++ treats all inline functions as "static", this problem went away. This is the only issue related to linkage that I am aware of.

We're also working really hard to get more widely deployed cross-module optimization strategies, in part to free programmers from the requirement that they put all their performance critical code in header files. That makes compilation faster, and has lots of benefits to the factoring and design of the code itself. We shouldn't then create an incentive to keep things in header files so that they pick up a hint to the optimizer.

The incentive is already there---this is a programming practice that has existed for a long time. We can provide alternative means (such as LTO) that are arguably better, but making existing practice worse for the programmer will not win too many people over.

-Krzysztof

-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

More information about the llvm-dev mailing list