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