DIP56 - inlining

[Paulo Pinto via Digitalmars-d]

On Wednesday, 4 February 2015 at 21:05:59 UTC, Zach the Mystic 
wrote:
> On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
> wrote:
>> On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
>>> On 2/4/15 4:02 AM, Walter Bright wrote:
>>>> On 2/4/2015 1:39 AM, ponce wrote:
>>>>> Would pragma(inline, <bool-expr>) be supported though?
>>>> Yes. That's what I intended, sorry the wording wasn't clear.
>>> Please nail it down in the doc so it doesn't get neglected. 
>>> -- Andrei
>>
>> Reading the DIP again,
>>
>> "This adds a pragma 'inline', which is followed by an optional 
>> boolean expression, which influences the inlining of the 
>> function it appears in. An evaluation of 'true' means always 
>> inline, 'false' means never inline, and no argument means the 
>> default behavior."
>>
>> Seems clear enough.
>
> Also, the "Rationale" seems outdated now too. Currently: 
> "Sometimes generating better code requires runtime profile 
> information. But being a static compiler, not a JIT, the 
> compiler could use such hints from the programmer."
>
> I would change that rationale to this one (feel free to confirm 
> and/or copy): "Programmers will sometimes want precise control 
> of the compiler's inlining behavior, either to improve 
> performance in debug builds, or to be completely sure that a 
> function is inlined, or to ensure access to the function's 
> runtime profiling information by not inlining it. This DIP 
> addresses those needs. Warning: Careless forcing of inlining 
> can decrease performance dramatically. Use with caution."
>
> Also, speaking of hints to the compiler:
>
> pragma(hotcodepath, true/false);
>
> ... seems really interesting to me, although that's clearly the 
> subject for a different DIP. I just wanted to emphasize that 
> the current DIP is not meant to address that feature.


Profile guided optimizations would also be an option I guess.

--
Paulo