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;
