inlining or not inlining...

[spir]

Hello,

Walter states that inline annotations are useless, since programmers cannot 
generally know which function /should/ be inlined --depending on a variety of 
factors, inlining may in fact be counter-productive.
I totally agree, even more after having (superficially) explored the topic 
(mainly in LLVM docs). This point of view addresses one face of the question: 
namely when a given piece of code will be "factored out" into a separate 
function in any case, and we just wish it could be inlined.

What if instead we wish this piece code inline in any case, even at the price 
of code duplication when it's used by several functions. The point is then 
different: we want to know whether the compiler will inline it, else we do it 
ourselves.

If the compiler does, we are free to write the source in the optimal form for 
clarity; else, we are left and doing our best to prevent code obfuscation. This 
issue often happens to me, maybe, because I have high expectations on clarity, 
so that I tend to make functions for anything conceptually representing a whole 
task, even if tiny, even if used only by a single client func. (Structured 
programming is before all, for me, a tool for clarity, not to avoid code dup.)

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. (*)

Denis

By the way, I would love a [rather big] tutorial on efficiency -- what do you 
think?
-- 
_________________
vita es estrany
spir.wikidot.com