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
