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

Eric Christopher echristo at gmail.com
Mon Feb 25 17:37:23 PST 2013


On Mon, Feb 25, 2013 at 5:34 PM, John McCall <rjmccall at apple.com> wrote:

> On Feb 25, 2013, at 5:14 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> On Mon, Feb 25, 2013 at 5:02 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Feb 25, 2013, at 4:55 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> > here’s another patch for review:
>> >
>> > Allocate stack storage for .block_descriptor and captured self.
>> > This way the register allocator will not optimize away the the
>> > debug info for captured variables.
>>
>> Allocating stack storage is not the right way to fix this problem.
>> The frontend is emitting the right intrinsics to say that the argument
>> is being kept in an LLVM value, not in memory.  If that's not working,
>> then basically all optimized debug info is useless.
>>
>>
> That's pretty accurate. The backend in a lot of places is depending upon an
> alloca existing in order to get a location for a variable. To make
> optimized
> debug info work we're going to need to fix that assumption.
>
>
> When did this become true?  I know that at least *some* debugging used
> to work in blocks, and we haven't been making allocas for them in a while.
> Maybe it was a really brittle, but some things used to survive at least to
> the
> point that GDB could consume them.
>
>
Nothing has changed as far as debug info, it was just always pretty brittle.


> If we *must* do this as a temporary debug info workaround, then the
> appropriate solution for things like the block descriptor is to make the
> alloca, slam a value into it, and use that for the debug info intrinsic,
> but
> not otherwise change IR-generation for the function.
>

Agreed, though there's something to be said for not changing it and fixing
the underlying problems in the backend.

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


More information about the cfe-commits mailing list