On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > 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?
pragma(hot/cold) or @attribute(hot/cold) This maps well in gdc's framework too.