inlining or not inlining...

[spir]

On 02/11/2011 07:32 AM, Walter Bright wrote:
> 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.

People possibly interested in the question of inlining (or more generally 
factors of (in)efficiency) must start somehow, granted. But making it even more 
difficult than necessary, while we all know it is inherently a very complex 
topic, does not bring much, don't you think?
In this case, I guess emitting such an information is very easy, since the 
compiler already needs to compute whether or not to inline. Or am I wrong and 
overlook a relevant point? On the other side, the feedback brought is extremely 
valuable; it allows learning by trial & error, and/or guided by a little howto 
as evoked above. Both count, and personal experience primes (I guess).

I have actually programmed some pieces of code in ASM (a very long time ago), 
so I know it is possible for normal people. But the barrier is still very high; 
and anyway one approach does not prevent the other, instead compiler feedback 
is very complementary to asm "contemplation" ;-) Don't you think so?
Even more, the compiler routine deciding on inlining probably has, at least 
partly, a form of checklist, so that the compiler could even say /why/... which 
would help much when decoding asm by giving some hint on /what/ to look for.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com