[PATCH] Debug info: Support fragmented variables.

David Blaikie dblaikie at gmail.com
Wed Feb 26 10:17:26 PST 2014


On Wed, Feb 26, 2014 at 10:11 AM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On Feb 26, 2014, at 3:06, Chandler Carruth <chandlerc at gmail.com> wrote:
>
>
> Thanks for the review, Chandler! Your comments raise good points and I
> will address them in the next revision.
>
> Regarding this one:
>
> > Comment at: lib/Transforms/Scalar/SROA.cpp:426-429
> > @@ -419,1 +425,6 @@
> >
> > +    // Make a best effort to find a dbg.declare intrinsic describing
> > +    // the alloca by peeking at the next instruction.
> > +    if (DbgDeclareInst
> *DDI=dyn_cast_or_null<DbgDeclareInst>(SI.getNextNode()))
> > +      S.DbgDeclare = DDI;
> > +
> > ----------------
> > This seems like a total hack.
> >
> > It papers over the fact that this is not relevant for a particular
> store, but for the entire alloca.
> >
> > Why can't we find this by locating the use of the alloca in the metadata
> and then the intrinsic using the metadata? I know it's a non-standard edge
> in the IR, but I was pretty sure it was still *an* edge in the IR somewhere
> that would let us find this?
> >
>
>
> Eric or David,
>
> _is_ there a canonical way to find a debug declare intrinsic for a
> specific alloca?


I doubt it. I don't think we have any side table that would store and keep
that information up to date (which is what we'd need for it to be anything
other than a linear scan through instructions). If that's something we
should have/is reasonable, I imagine we could add one.


> I had this problem before, and the best I could come up with was to scan
> through every instruction and then check whether it is a debug intrinsic
> and describes that alloca, but IMO that's too expensive, which is why I
> write code like the snippet above.
>
> thanks,
> Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140226/71dc536c/attachment.html>


More information about the llvm-commits mailing list