[llvm-dev] Tracking parts of expanded values in optimized debug

Ed Jones via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 7 01:26:13 PST 2017


Okay, I'll take a look at that patch and see if it gives me any ideas.

On 2 February 2017 at 16:42, Adrian Prantl <aprantl at apple.com> wrote:

>
> > On Feb 2, 2017, at 5:16 AM, Ed Jones via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > I'm currently working on an out-of-tree backend and am trying to
> > improve the debug experience when debugging optimized code. Our
> > backend only has 8-bit and 16-bit legal types, so any larger values
> > are expanded. The behavior I am currently seeing is that the expanded
> > halves of an illegal type lose their debug information. Is this the
> > expected behavior?
> >
> > For example, if I have an ISD::DBG_VALUE SDNode associated with a
> > value, and that value is split up (for example a i64 load expanded
> > into two i32 loads), I would expect to see a new ISD::DBG_VALUE
> > tracking each fragment of the input original debug variable. However,
> > I can't see anywhere this is handled. There seems to be some support
> > for this, through the DW_OP_LLVM_fragment DIExpression, and there is a
> > function DIBuilder::createFragmentExpression which could be used to
> > create an expression to track part of a variable, however these don't
> > seem to be used much.
>
> Support for fragmented variables is (relatively) new and so far only
> implemented for SROA. Patches that extend support to other passes would be
> very welcome! You can find also a WIP patch in phabricator that adds
> support for TypeLegalizer that would need to be picked up by somebody.
>
> -- adrian
>
> >
> > Thanks,
> > Ed
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/003368df/attachment.html>


More information about the llvm-dev mailing list