[LLVMdev] Inline hint for methods defined in-class
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