This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Live range splitting in new allocator
- To: meissner at cygnus dot com, gcc at gcc dot gnu dot org
- Subject: Re: Live range splitting in new allocator
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Mon, 29 Jan 2001 11:20:40 -0800
- Newsgroups: linux.egcs
- References: <Pine.LNX.4.31.0101291127110.7957-100000@www.cgsoftware.com>
In article <20010129135420.G13475@cse.cygnus.com> you write:
>
>In addition to the dataflow problems, another problem that I haven't had time
>to work on is how to inform the debugger of a variables location as it moves
>betweent he stack and multiple registers. The current compiler is broken in
>this regard, but LRS makes it more visible, since things can be in multiple
>registers for a longer time.
The debugger problem comes up not infrequently as a reason for gcc doing
the wrong thing.
Would it not be reasonable at some point to say "Ok, our debug
information is going to be bad, but let's do the RightThing(tm) anyway,
and fix the debug information _afterwards_".
Now, I'm obviously biased, as I think that the main reason for a
debugger is to get a backtrace and not much more. But if debugging is
holding back good register allocation, then somebody should realize that
register allocation is just about the most important thing a compiler
can do, and that bad debugging infrastructure will never ever get
improved if it never gets a _reason_ to improve.
So please at least consider breaking debugging. It _will_ get fixed -
too many people care about it. But it should not get fixed by
generating bad code.
Linus