[PATCH] Allocate stack storage for .block_descriptor and captured self.

Eric Christopher echristo at gmail.com
Wed Feb 27 15:17:16 PST 2013


On Wed, Feb 27, 2013 at 11:49 AM, John McCall <rjmccall at apple.com> wrote:

> On Feb 27, 2013, at 11:42 AM, Eric Christopher <echristo at gmail.com> wrote:
>
> On Wed, Feb 27, 2013 at 11:39 AM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Feb 27, 2013, at 11:31 AM, John McCall <rjmccall at 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.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130227/d4251b8e/attachment.html>


More information about the cfe-commits mailing list