On Feb 28, 2013, at 11:20 AM, John McCall <[email protected]> wrote:
> On Feb 28, 2013, at 11:12 AM, Eric Christopher <[email protected]> wrote: >> On Thu, Feb 28, 2013 at 11:06 AM, John McCall <[email protected]> wrote: >> 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. >> >> Thought if optimization should fix it then perhaps all builds? :) > > I don't see any point in creating it just for mem2reg to trivially destroy. :) > >> That said I'll remove the objection to the allocas. We'll need to fix the >> alloca problem at some point, but making poor Adrian do it right now for >> this bug when we've got other workarounds already in the source base seems a >> bit mean. > > Well, if the value really isn't live anymore, then I'm not sure what the > supposed alloca problem is, other than needing to leave breadcrumbs to say > that the value isn't available at this point in the function. We definitely > don't want regalloc to be keeping values live just for debug info! FYI: this is what the patch looks like if output the alloca only at -O0. -- adrian
0001-Allocate-stack-storage-for-.block_descriptor-and-cap.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
