On 11/25/07 3:43 PM, Mark Mitchell wrote:
My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
GCC developer with an interest in improving the compiler in the same way
that you're trying to do) is that you stop writing code and start
writing a paper about what you're trying to do.
Ignore the implementation. Describe the problem in detail. Narrow its
scope if necessary. Describe the success criteria in detail. Ideally,
the success criteria are mechanically checkable properties: i.e., given
a C program as input, and optimized code + debug information as output,
it should be possible to algorithmically prove whether the output is
correct.
Yes, please. I would very much like to see an abstract design document
on what you are trying to accomplish. I have been trying to follow this
thread but I've gotten lost. It's full of implementation details,
rhetoric and high-level discussion.
I would like to see exactly what Mark is asking for. Perhaps a
presentation in next year's Summit? I don't think I understand the goal
of the project. "Correct debugging info" means little, particularly if
you say that it's not debuggers that you are thinking about.
It's certainly worrisome that your implementation seems to be intrusive
to the point of brittleness. Will every new optimization need to think
about debug information from scratch and refrain from doing certain
transformations?
In my simplistic view of this problem, I've always had the idea that -O0
-g means "full debugging bliss", -O1 -g means "tolerable debugging"
(symbols shouldn't disappear, for instance, though they do now) and -O2
-g means "you can probably know what line+function you're executing".
But you seem to be addressing other problems. And it even seems to me
that you want debugging information that is capable of deconstructing
arbitrary transformations done by the optimizers. But I think I'm just
lost in this thread, so a high-level design document would be perfect to
expose your ideas.
Diego.
