DIP56 Provide pragma to control function inlining

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 23 21:26:49 PST 2014


On 2/23/14, 8:26 PM, Vladimir Panteleev wrote:
> On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu wrote:
>> I'll add an anecdote - in HHVM we owe a lot of speedups to the careful
>> use of "never inline" and "always inline" gcc pragmas IN ADDITION TO
>> the usual "inline" directives. We have factual proof that gcc makes
>> the wrong inline decisions BOTH WAYS if left to decide.
>>
>> If we define pragmas for inlining, "always inline" must mean always
>> inline no questions asked and "never inline" must mean always prevent
>> inlining no questions asked. Anything else would be a frustrating
>> waste of time.
>
> I think there is another, distinct use case for an inline pragma where
> "try to inline" is useful - namely, turning on the equivalent of the
> compiler "-inline" switch for just one function. I believe this is the
> original rationale behind the DIP (enabling inlining for certain
> functions even in debug builds, because otherwise the debug builds
> become so slow as to be unusable). In this case, whether the compiler
> actually succeeds at inlining the function doesn't matter as long as it
> does the same thing as for an optimized (-inline) build.
>
> Thus, I think there should be "try to inline" (same as -inline) and
> "always inline" (failure stops compilation).

Sounds fair enough.

Andrei



More information about the Digitalmars-d mailing list