On 3 February 2015 at 11:15, Iain Buclaw <[email protected]> wrote: > On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d > <[email protected]> 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.
Also 'flatten' - which allows you to control inlining at the caller, rather than the callee.
