DIP56 Provide pragma to control function inlining

[deadalnix]

On Monday, 24 February 2014 at 16:58:21 UTC, Manu wrote:
> For those interested, in my experience, the value of inlining 
> is rarely
> related to eliminating the cost of the function call. call and 
> ret have
> virtually no impact on performance on any architecture I've 
> used.

It highly depends on the architecture you run on. X86 is
astonishingly good at this.

> The main value is that it eliminates stuffing around with 
> parameter lists,
> and managing save registers. Also, some argument types can't 
> pass in
> registers, which means they pass through memory, and memory 
> access should
> be treated no differently from the hard drive in realtime code 
> ;) .. The
> worst case is a write followed by an immediate read 
> (non-register argument,
> or save register value); some architectures stall waiting for 
> the full
> flush before they can read it back. It's called a 
> Load-Hit-Store hazard,
> and it's the most expensive low level hazard short of an L2 
> miss.

All modern architecture (if I put aside PIC) that I know of have
a store buffer to avoid this.

Also, not inlining prevent the compiler to do constant
propagation, and as such, prevent the compiler from doing a lot
of optimizations.

> I agree that inline should be a hint (a STRONG hint, not like 
> 'inline' in
> C, more like __force_inline, perhaps stronger), but I'd like it 
> if I
> received a warning when it failed for whatever reason. I don't 
> want it to
> stop compiling, but a nice notification that I should look into 
> it, and the
> ability to disable/silence the warning if I can't/don't intend 
> to.

Proposed semantic:
Inline unless for some reason you cannot. If you cannot, warn
about it.