H1 2015 Priorities and Bare-Metal Programming

[Iain Buclaw via Digitalmars-d]

On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d
<digitalmars-d at 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.