inlining or not inlining...

[spir]

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 ;-)
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
-- 
_________________
vita es estrany
spir.wikidot.com