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.
