[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-commits
Subject: Re: [PATCH] Allocate stack storage for .block_descriptor and captured self.
From: John McCall <rjmccall () apple ! com>
Date: 2013-02-28 19:06:53
Message-ID: CCE92460-1B89-41BE-AD5D-96EDA2757F2E () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Feb 27, 2013, at 3:17 PM, Eric Christopher <echristo@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 11:49 AM, John McCall <rjmccall@apple.com> wrote:
> On Feb 27, 2013, at 11:42 AM, Eric Christopher <echristo@gmail.com> wrote:
> > On Wed, Feb 27, 2013 at 11:39 AM, Adrian Prantl <aprantl@apple.com> wrote:
> >
> > On Feb 27, 2013, at 11:31 AM, John McCall <rjmccall@apple.com> 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.
[Attachment #5 (text/html)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; -webkit-line-break: after-white-space; "><div><div>On Feb 27, 2013, at 3:17 \
PM, Eric Christopher <<a \
href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><blockquote \
type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, \
Feb 27, 2013 at 11:49 AM, John McCall <span dir="ltr"><<a \
href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>On Feb 27, 2013, \
at 11:42 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" \
target="_blank">echristo@gmail.com</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote">On Wed, Feb 27, 2013 at 11:39 AM, Adrian Prantl <span \
dir="ltr"><<a href="mailto:aprantl@apple.com" \
target="_blank">aprantl@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
On Feb 27, 2013, at 11:31 AM, John McCall <<a href="mailto:rjmccall@apple.com" \
target="_blank">rjmccall@apple.com</a>> wrote:<br> > 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.<br>
><br>
> 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.<br> \
<br> </div>To clarify: Are you suggesting to only generate the alloca at -O0, or are \
you comfortable with it as it is?<br></blockquote><div><br></div><div>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.</div>
</div></div></div></blockquote><br></div><div>Purely out of attachment to the \
principle that debug info shouldn't change the \
code?</div><div><br></div></div></blockquote><div><br></div><div>Pretty much.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div></div><div>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.</div>
<span><font color="#888888"><br></font></span></div></blockquote><div><br></div><div>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.</div>
</div></div></div></blockquote><br></div><div>Ah, I see your point; not doing \
the alloca could slide stack frames around.</div><div><br></div><div>Alright, I agree \
with emitting it in all -O0 \
builds.</div><div><br></div><div>John.</div><br></body></html>
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic