inlining...

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:
> The idea of eliminating common sub-expressions suggests that 
> there _are_
> common sub-expressions, which aren't affected by the function 
> arguments.
> This case is highly unusual in my experience.

Not if you delay optimization until profiling and focus on higher 
level structures during initial implementation. Or use composing 
(like generic programming).

If you hand optimize right from the start then you might be 
right, but if you never call a function with the same parameters 
then you are doing premature optimization IMHO.

>> When the function is generated code (not hand written).
>
> I'm not sue what you mean here?

Code that is generated by a tool (or composable templates or 
whatever) tend to be repetitive and suboptimal. I.e. boiler plate 
code that looks like it was written by a monkey…

>> You already have that. It is sugar.
>>
>
> I don't already have it, otherwise I'd be making use of it. D 
> has no control over the inliner.

I meant that if you have explicit inline hints like C++ then you 
also have call-site inlining if you want to.

> I also don't think that suggestion of yours works. I suspect 
> the compiler
> will see the outer function as a trivial wrapper which will 
> fall within the
> compilers normal inline heuristics, and it will all inline 
> anyway.

That should be considered a bug if it is called from more than 
one location.