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

[Eric Christopher]

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

> On Feb 25, 2013, at 5:37 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> 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.
>
>
> Right;  the problems in the backend definitely need to be fixed.  I am just
> skeptical that anybody working on the backend cares enough to fix them.
> If we can avoid this workaround, we should.
>
>
Mm.. the only problem here is that we then have the presence of debug info
intrinsics
changing the generated code - normally a big no-no...

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