This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Live range splitting in new allocator
In article <20010130144032.A26921@hg.cs.mu.oz.au> you write:
>
>How about some generalization of the `-fomit-frame-pointer' option,
>e.g. `-fundebuggable-optimizations', which tells the compiler that it
>is OK to perform optimizations that might break the debugger?
>`-fundebuggable-optimizations' could imply `-fomit-frame-pointer',
>and would also permit live range splitting and other things which
>prevent debugging. Compiling with `-g -fundebuggable-optimizations'
>would be allowed, although it might be nice for the compiler to issue
>a warning about that combination.
The thing is, live range splitting doesn't really prevent debugging.
It requires a lot of extra care in outputting the debug information, and
it does need a lot of extra knowledge by the debugger in _understanding_
the debug information, but it doesn't make it impossible.
The problem is that this is pretty much a chicken-and-egg issue: before
you've done it, you don't have the reason to do debug infrastructure
that you can't even test, and before you have the debug infrastructure
you feel that you shouldn't do it. This is why I suggested dropping the
chicken, and concentrate just on the egg at some point..
Even "fomit-frame-pointer" shouldn't really cause undebuggability: the
compiler knows what it is doing with the stack pointer, and can tel the
debugger about it. Making the debug sections contain stack pointer
depth and variable liveness section on a per-instruction basis should
not be fundamentally impossible. Complex, yes.
It's to a large degree the same issue as being able to take an exception
anywhere and being able to unwind the stack. It's easier if you drop
the "anywhere" and only support synchronous exceptions. Or you can make
it easier by limiting what kind of code you generate - and live with the
fact that you generate bad code.
If it has to be done with an extra flag, so be it. I use
"-fomit-frame-pointer" everywhere - I actually think the assembly code
tends to be a lot more readable that way because of the extra register
that makes for fewer spills. And I always debug on a source level
anyway, so it doesn't end up being a problem for me.
But the option should NOT be called "-fundebuggable-optimizations".
That's like having an option that says "-fstupid-compiler". It's not
undebuggable - it's just a limitation of the compiler (and/or the debug
interface itself, of course - some debug interfaces just can't handle
the level of detail you need to debug the code). Make it say
"-fsplit-ranges", and if people want to use it with -g, let them.
Linus