H1 2015 Priorities and Bare-Metal Programming

[John Colvin via Digitalmars-d]

On Monday, 2 February 2015 at 23:29:26 UTC, Walter Bright wrote:
> Now, when it can't inline, do you expect the compiler to 
> produce an error message?

Just to add support:
Yes, exactly that.

> If so, what corrective action is the user faced with:

Change the function so it can be inlined, or remove the pragma.


Yes, there are many other optimisations that matter, but I think 
inline is special and so do a bunch of other users.

Just one example:

You write a simple expression that does operation A, in a tight 
loop.
You look at the assembly and see that it is for some reason 
terribly unnecessarily slow, especially in debug builds.
To get the sort of asm you want, you implement a rather nasty, 
messy little function to do the operation, which internally uses 
intrinsics and/or lots of casts etc. that you don't want lying 
around in your normal code.
You now have a choice: copy and paste the contents everywhere you 
need it, or pay for the function call in debug builds (and 
perhaps optimised too, if the compiler decides it doesn't feel 
like inlining it).

With an actual guarantee of inlining, the problem goes away. 
Strap a pragma(always_inline) on the function and carry on.

Hints are great, but sometimes commands are necessary.

Guaranteed inlining makes it possible to have fast debug builds, 
because it lets you abstract away ugly hand-tuned code at 
guaranteed zero cost.