On 2/2/2015 8:36 PM, Daniel Murphy wrote:
If so, what corrective action is the user faced with:
The user can modify the code to allow it to be inlined. There are a huge number
of constructs that cause dmd's inliner to completely give up. If a function
_must_ be inlined, the compiler needs to give an error if it fails.
I'd like to reexamine those assumptions, and do a little rewinding.
The compiler offers a -inline switch, which will inline everything it can.
Performance oriented code will use that switch.
So why doesn't the compiler inline everything anyway? Because there's a downside
- it can make code difficult to symbolically debug, and it makes for
difficulties in getting good profile data.
Manu was having a problem, though. He wanted inlining turned off globally so he
could debug his code, but have it left on for a few functions where not inlining
them would make the debug version too slow.
pragma(inline,true) tells the compiler that this function is 'hot', and
pragma(inline, false) that this function is 'cold'. Knowing the hot and cold
paths enables the optimizer to do a better job.
There are literally thousands of optimizations applied. Plucking exactly one out
and elevating it to a do-or-die status, ignoring the other 999, is a false god.
There's far more to a programmer reorganizing his code to make it run faster
than just sprinkling it with "forceinline" pixie dust.
There is a lot of value to telling the compiler where the hot and cold parts
are, because those cannot be statically determined. But exactly how to achieve
that goal really should be left up to the compiler implementer. Doing a better
or worse job of that is a quality of implementation issue, not a language
specification issue.
Perhaps the fault here is calling it pragma(inline,true). Perhaps if it was
pragma(hot) and pragma(cold) instead?
