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.
