[LLVMdev] Inline hint for methods defined in-class

[Chandler Carruth]

On Wed, Jul 8, 2015 at 2:48 PM Krzysztof Parzyszek <kparzysz at codeaurora.org>
wrote:

> 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.
>

Yes, and I suggested just such a strategy.


>
>
> > 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.
>

I did in my email to David Li. To get more concrete, method definitions of
class templates must be inline regardless of whether they make any sense at
all to inline in the optimizer.


>
>
> > 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.
>

I'm not trying to make things worse. I'm not arguing to actively harm
anything to incentivize anything. I'm suggesting that we should be
decoupling our optimization hints from using a specific linkage or writing
code in a header file versus a source file. That way they work both today,
and in any future LTO model folks are using. (And some folks are using LTO
today.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150709/8e23b56c/attachment.html>