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