inlining or not inlining...

[Walter Bright]

spir wrote:
> On 02/11/2011 08:11 PM, Walter Bright wrote:
>> bearophile wrote:
>>>> 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?
>>>
>>> Inlining is an important optimization, so give this information to the
>>> programmer is a good start.
>>
>> Register allocation is far more important than inlining. Why not give
>> information about why a variable was not enregistered?
> 
> Because we do not ask for it ;-)

Actually, that is a good reason.

> Joke apart, I would love that too, on tiny test apps indeed. Why not? 
> Since the decision-taking exist (and is certainly well structured around 
> its criteria), why not allow it writing out its "reasoning"?
> 
> About inline, note that no-one asks for information on every potentially 
> inlinable func, blindly. But having a way to know that about /this/ func 
> one is wondering about would be great: just append @inline to it, 
> recompile, et voilà! you know :-) (provided you can interpret the 
> output, but it's another story)
> 
> <side-note>
> If I were a compiler writer, no doubt my code would hold snippets 
> dedicated to spitting out such information, on need. For myself, as a 
> testing tool to check the code really does what I mean. This is integral 
> part of my coding style. Else, how can I know? Checking the ASM indeed 
> can tell you, but it seems to me far more heavy & complicated than 
> following the trace of a "reasoning", and tells nothing about 
> where/why/how the encoded logic fails.
> Then, if this can be useful to users...
> <side-note>
> 
> Denis