H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/3/2015 2:10 AM, Daniel Murphy wrote:
> The inliner in dmd fails to inline many constructs, loops for example.

It will inline a loop if the function is called at the statement level. The 
trouble with inlining a loop inside an expression is that is not expressible in 
the expression tree used in the back end.

Obviously, inlining functions with loops tend to have lower payoffs anyway, 
because the loop time swamps the function call overhead. Inlining a loop can 
even make things worse, because the loop variables may not get priority for 
enregistering whereas they would if in a separate function.

I.e. it is not a trivial issue of "inlining is faster".

> It would succeed on all of the cases relevant to wrapping mmio.

Yup. I understand the concern that a compiler would opt out of inlining those if 
it legally could, but I just cannot see that happening in reality. Modern 
compilers have been inlining for 25 years now, and they're not likely to just 
stop doing it. It's as unlikely as the compiler failing to rewrite:

    x *= 32;

into:

    x <<= 5;