inlining or not inlining...

[Walter Bright]

spir wrote:
> Thus, at best, we would need to know a bit about criteria used by the 
> compiler for deciding whether to inline or not; provided a doc 
> explaining this is at all readable by people who do not have the 
> compiler-writer gene.
> Aside that, let us imagine an inline annotation beeing, not a request 
> for inlining, but a request for compiler warning emission when inlining 
> would not be applied to a given annotated func. Then, programmers would 
> at least know, beeing thus able to choose on an informed basis.
> Complement to that may be a little (and hopefully clear) how-to guide on 
> "best chances to get a func inlined". This howto would start by 
> describing most common and/or most critical criteria for the compiler to 
> /not/ inline a given func. Then, a short set of negative & positive 
> examples actually generating or not the fatal warning.
> As a nice side-effect, such a doc may help & make clear some schemes of 
> (in)efficiency, in general, even for an inlined piece of code. (*)

While in isolation that's a good idea, how far should it be taken? Should the 
compiler emit information on which variables wound up in which registers, and 
why? What about other of the myriad of compiler optimizations?

Also, if you're willing to look at the assembler output of the compiler, it's 
pretty trivial to see if a function was inlined or not. If you're interested in 
optimizing at that level, I think it would make sense to get familiar with the 
asm output.


> By the way, I would love a [rather big] tutorial on efficiency -- what 
> do you think?

My advice is to start with -cov and -profile.