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
