On Wed, Feb 27, 2013 at 11:49 AM, John McCall <[email protected]> wrote:
> On Feb 27, 2013, at 11:42 AM, Eric Christopher <[email protected]> wrote: > > On Wed, Feb 27, 2013 at 11:39 AM, Adrian Prantl <[email protected]> wrote: > >> >> On Feb 27, 2013, at 11:31 AM, John McCall <[email protected]> wrote: >> > Okay, you're saying that the value is actually no longer live at all at >> this point in the function? It seems reasonable to lose track of the debug >> info then, although we should be leaving behind a marker in the DWARF that >> says the value is unavailable. >> > >> > If we want to make stronger guarantees in -O0 for purposes of debugging >> — and I think that's reasonable — then throwing the value in an alloca is >> acceptable. >> >> To clarify: Are you suggesting to only generate the alloca at -O0, or are >> you comfortable with it as it is? >> > > If the value isn't live past that spot I'm more comfortable with dropping > the debug info there rather than changing the generated code to keep the > value live through the end of the function. > > > Purely out of attachment to the principle that debug info shouldn't change > the code? > > Pretty much. > Not losing information has intrinsic value in a debug build. If we need > to emit slightly different code in order to force a value to stay live and > thus improve the debugging experience, then so be it. > > Agreed that making the experience better is desirable, but it can make debugging a problem more difficult if the code changes when you turn on debugging symbols. -eric
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
