On Feb 27, 2013, at 3:17 PM, Eric Christopher <[email protected]> wrote: > 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.
Ah, I see your point; not doing the alloca could slide stack frames around. Alright, I agree with emitting it in all -O0 builds. John.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
