Inline Functions

[Walter Bright]

Jarrett Billingsley wrote:
> True.  However defining what the compiler does in these optimizations
> is not just in the interest of performance, but also in the interest
> of correctness and other implementations.

Optimization should have nothing to do with correctness.

> If everyone can see what
> DMD is and isn't inlining, they can ask "why" or "why not"; they can
> correct you if you make a mistake; they can suggest optimizations you
> might not have thought of; and they can see optimizations that fall
> out as a consequence of the language that they might not have
> considered when making their own compiler.

If they're working at that level, why avoid looking at the compiler 
source? Optimization suggestions from someone who knows how compilers 
work are much more likely to be viable.

> Furthermore things like NRVO either need to be specified in the
> language or specified in the ABI.  You told me before that static
> opCall for structs is just as efficient as constructors because of
> NRVO; I didn't and still don't buy it for exactly the reasons you just
> now gave: optimizations are highly implementation-dependent.  It's
> this kind of stuff that needs to be specified: is NRVO required, or
> just _really really nice to have_?  Insert many other optimizations
> here.

If an optimization is required, then yes, it needs to go in the spec. 
But inlining is not required.

Let me put it another way. There are *thousands* of optimizations the 
compiler does, and they often have some very complex interactions. Even 
enumerating them all would be an enormous time sink. There's nothing 
particularly special about inlining as opposed to constant folding, dead 
code elimination, register allocation, instruction scheduling, strength 
reduction, etc., etc.

Even if I wrote such a tome, it would be a waste of time to read it. The 
easiest, quickest way to see if an optimization happened is to look at 
the obj2asm output.

Remember the thread a while back about how dmd did a terrible job 
generating arithmetic code? A quick check with obj2asm showed that the 
speed problem had nothing to do with the code generation, it was all 
sucked up by a library module (since fixed).