[LLVMdev] Inline hint for methods defined in-class

[Krzysztof Parzyszek]

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