On Mon, Feb 25, 2013 at 5:34 PM, John McCall <[email protected]> wrote:
> On Feb 25, 2013, at 5:14 PM, Eric Christopher <[email protected]> wrote: > > On Mon, Feb 25, 2013 at 5:02 PM, John McCall <[email protected]> wrote: > >> On Feb 25, 2013, at 4:55 PM, Adrian Prantl <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
