llvm dev - Feb 2017 - Tracking parts of expanded values in optimized debug

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.

Thanks,
Ed

Debug info for optimized code is not well supported in LLVM - there's lots
that's not done/could be done to improve it.

I know Adrian's been looking at optimized code debug info for a bit
recently & not sure if this particular situation is on his radar or not.

On Thu, 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.
>
> 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/20170202/123fbcf6/attachment-0001.html>

> 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

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>