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

[John McCall]

On Feb 25, 2013, at 5:52 PM, Eric Christopher <echristo at gmail.com> wrote:
> 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...

As far as I'm concerned, it's only really a problem if it's unintentional. :)

John.

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