thr3ads.net - llvm dev - [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred [Apr 2018]

If this information is useful, please help other people find it:
Share via:

Adrian Prantl via llvm-dev

2018-Apr-30 20:52 UTC

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

> On Apr 30, 2018, at 1:49 PM, Se Jong Oh <sejooh at microsoft.com>
wrote:
> 
> Hi Jonas,
> 
> I have another case that DBG_VALUE is not produced. I would appreciate it
if you could take a quick look at the testcase below.
> 
> 
> test code:
> 
> llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll
> 
> ; Function Attrs: nounwind ssp uwtable
> define void @f() #0 !dbg !4 {
> entry:
>  tail call void @h(i16 0) #2, !dbg !14
>  %call = tail call i16 (...) @g() #2, !dbg !15
>  tail call void @llvm.dbg.value(metadata i16 %call, metadata !8, metadata
!16), !dbg !17
>  tail call void @h(i16 %call) #2, !dbg !18
>  ret void, !dbg !19
> }
> 
> For the second call, the AArch64 ISel lowering produces a 32-bit
CopyFromReg from w0.
> 
>  t18: ch,glue = AArch64ISD::CALL t15, TargetGlobalAddress:i64<i16 (...)*
@g> 0, RegisterMask:Untyped, test.c:5:11
>  t19: ch,glue = callseq_end t18, TargetConstant:i64<0>,
TargetConstant:i64<0>, t18:1, test.c:5:11
>  t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11
> 
> Then, TargetLowering::LowerCallTo adds a truncate node since the function
return type is i16.
> 
> t21: i16 = truncate t20, test.c:5:11
> 
> When lowering the dbg.value intrinsic, a SDDbgValue node is attached to the
truncate since it is the final result of the call.
> 
> Lowering the third call constructs any_extend(t21) for the 32-bit register
type but optimizes out the truncate node by the following code, and it seems
that the DbgValue node on the truncate is also lost.
Without having looked at this in more detail: there is a facility called
salvageDebugInfo that is supposed to be called on instructions and SDag nodes
right before they are deleted and it attempts to attach the debug info of the
dying node to another node in situations where this is possible and correct.

-- adrian
> 
> SelectionDAG::getNode(...)
> ...
>    // (ext (trunx x)) -> x
>    if (OpOpcode == ISD::TRUNCATE) {
>      SDValue OpOp = Operand.getOperand(0);
>      if (OpOp.getValueType() == VT)
>        return OpOp;
>    }
> 
> I am wondering if we can just transfer the dbg node here or we can have a
better solution.
> 
> 
> The entire test file is here:
> 
> ; ModuleID = 'test.ll'
> target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-apple-macosx"
> 
> ; Function Attrs: nounwind ssp uwtable
> define void @f() #0 !dbg !4 {
> entry:
>  tail call void @h(i16 0) #2, !dbg !14
>  %call = tail call i16 (...) @g() #2, !dbg !15
>  tail call void @llvm.dbg.value(metadata i16 %call, metadata !8, metadata
!16), !dbg !17
>  tail call void @h(i16 %call) #2, !dbg !18
>  ret void, !dbg !19
> }
> 
> declare void @h(i16)
> 
> declare i16 @g(...)
> 
> ; Function Attrs: nounwind readnone
> declare void @llvm.dbg.value(metadata, metadata, metadata) #1
> 
> attributes #0 = { nounwind ssp uwtable
"no-frame-pointer-elim"="true" }
> attributes #1 = { nounwind readnone }
> attributes #2 = { nounwind }
> 
> !llvm.dbg.cu = !{!0}
> !llvm.module.flags = !{!10, !11, !12}
> !llvm.ident = !{!13}
> 
> !0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer:
"clang version 3.9.0 ", isOptimized: true, runtimeVersion: 0,
emissionKind: FullDebug, enums: !2)
> !1 = !DIFile(filename: "test.c", directory:
"/Volumes/Data/llvm")
> !2 = !{}
> !4 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line:
3, type: !5, isLocal: false, isDefinition: true, scopeLine: 3, isOptimized:
true, unit: !0, variables: !7)
> !5 = !DISubroutineType(types: !6)
> !6 = !{null}
> !7 = !{!8}
> !8 = !DILocalVariable(name: "a", scope: !4, file: !1, line: 5,
type: !9)
> !9 = !DIBasicType(name: "int", size: 32, align: 32, encoding:
DW_ATE_signed)
> !10 = !{i32 2, !"Dwarf Version", i32 2}
> !11 = !{i32 2, !"Debug Info Version", i32 3}
> !12 = !{i32 1, !"PIC Level", i32 2}
> !13 = !{!"clang version 3.9.0 "}
> !14 = !DILocation(line: 4, column: 3, scope: !4)
> !15 = !DILocation(line: 5, column: 11, scope: !4)
> !16 = !DIExpression()
> !17 = !DILocation(line: 5, column: 7, scope: !4)
> !18 = !DILocation(line: 6, column: 3, scope: !4)
> !19 = !DILocation(line: 7, column: 1, scope: !4)
> 
> 
> Thanks,
> Sejong
> 
> -----Original Message-----
> From: jdevlieghere at apple.com <mailto:jdevlieghere at apple.com>
<jdevlieghere at apple.com <mailto:jdevlieghere at apple.com>>
> Sent: Thursday, March 15, 2018 8:43 AM
> To: Se Jong Oh <sejooh at microsoft.com <mailto:sejooh at
microsoft.com>>
> Cc: Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>>;
llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; Adrian
Prantl <aprantl at apple.com <mailto:aprantl at apple.com>>;
pidgeot18 at gmail.com <mailto:pidgeot18 at gmail.com>
> Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't
transferred
> 
> 
> 
>> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com>
wrote:
>> 
>> Hi Jonas,
>> 
>> Thanks for taking a look! It makes linear-dbg-value.ll pass for my
target by producing DEBUG_VALUEs correctly. I also tried a simple function with
few operations and confirmed DEBUG_VALUEs which are not produced without
trasferDbgValues in SetPromotedInteger.
> 
> That’s great news! Do you plan on creating a patch for this upstream? 
> 
>> 
>> Thanks,
>> Sejong
>> 
>> From: jdevlieghere at apple.com <jdevlieghere at apple.com> 
>> Sent: Wednesday, March 14, 2018 4:07 AM
>> To: Se Jong Oh <sejooh at microsoft.com>
>> Cc: Vedant Kumar <vsk at apple.com>; llvm-dev at lists.llvm.org;
Adrian Prantl <aprantl at apple.com>; pidgeot18 at gmail.com
>> Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't
transferred
>> 
>> Hi Sejong,
>> 
>> Indeed, I think you are right and we should call transferDbgValues in
SetPromotedInteger.
>> 
>> I couldn’t immediately find a suitable in-tree test to verify this
though. Can you check and let me know whether this works for your target?
>> 
>> Thanks,
>> Jonas
>> 
>> 
>> On Mar 13, 2018, at 7:45 PM, Se Jong Oh <sejooh at microsoft.com>
wrote:
>> 
>> Thanks for help! I think that sign extension is not involved here.
PromoteIntegerResult is called since i32 is not a legal type in my target and
the legalizer promotes operations with i32 result type to i64 operations. I
think that SetPromotedInteger seems to be a common place for all promotions like
SetExpandedInteger.
>> 
>> Jonas, I would appreciate it if you can guide me about whether my
understanding is correct or not.
>> 
>> Thanks,
>> Sejong
>> 
>> 
>> 
>> From: vsk at apple.com <vsk at apple.com> 
>> Sent: Friday, March 9, 2018 3:19 PM
>> To: Se Jong Oh <sejooh at microsoft.com>
>> Cc: llvm-dev at lists.llvm.org; Jonas Devlieghere <jdevlieghere at
apple.com>; Adrian Prantl <aprantl at apple.com>; pidgeot18 at
gmail.com
>> Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't
transferred
>> 
>> + Adrian, Joshua
>> + Jonas, since he contributed the transferDbgValues change in
DAGTypeLegalizer::SetExpandedInteger
>> 
>> On Mar 8, 2018, at 5:44 PM, Se Jong Oh via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> Hi,
>> 
>> I have a problem that dbg_value nodes are not transferred when integer
DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add
node by DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not
transferred to the new node.
>> 
>> t9: i32 = add nsw t5, t8 à  t31: i64 = add t30, t7   ; the dbg_value
node is not transferred to the new i64 add node.
>> 
>> For expansion, DAGTypeLegalizer::SetExpandedInteger calls
transferDbgValues() but I couldn’t find any place to call trasnferDbgValues()
for integer type promotion in DAGTypeLegalizer ::SetPromotedInteger and other
places.
>> 
>> Maybe the right place to do this is within the PromoteIntRes_ helper
for sign extensions?
>> 
>> best,
>> vedant
>> 
>> 
>> 
>> I am wondering If I miss anything or the legalization needs to call
transferDbgValues() for this case.
>> 
>> I found this problem because a recently added unittest,
DebugInfo/X86/linear-dbg-value.ll fails for my project, and the x86 and aarch64
backends don’t have this problem since they don’t promote i32 add nodes.
>> 
>> Thanks,
>> Sejong
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Csejooh%40microsoft.com%7C1334821c889d440e50ae08d58a8b6a62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567253755049370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=dmkgOHDLY6YWx1SISIdOg8a%2BC5hpT3mITrZZGwV715E%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Csejooh%40microsoft.com%7C1334821c889d440e50ae08d58a8b6a62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567253755049370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=dmkgOHDLY6YWx1SISIdOg8a%2BC5hpT3mITrZZGwV715E%3D&reserved=0>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/561e265b/attachment-0001.html>

Se Jong Oh via llvm-dev

2018-Apr-30 21:57 UTC

head link

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with
constant.

Sejong

From: aprantl at apple.com <aprantl at apple.com>
Sent: Monday, April 30, 2018 1:53 PM
To: Se Jong Oh <sejooh at microsoft.com>
Cc: jdevlieghere at apple.com; Vedant Kumar <vsk at apple.com>; llvm-dev
at lists.llvm.org; pidgeot18 at gmail.com
Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

On Apr 30, 2018, at 1:49 PM, Se Jong Oh <sejooh at
microsoft.com<mailto:sejooh at microsoft.com>> wrote:

Hi Jonas,

I have another case that DBG_VALUE is not produced. I would appreciate it if you
could take a quick look at the testcase below.

test code:

llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll

; Function Attrs: nounwind ssp uwtable
define void @f() #0 !dbg !4 {
entry:
 tail call void @h(i16 0) #2, !dbg !14
 %call = tail call i16 (...) @g() #2, !dbg !15
 tail call void @llvm.dbg.value(metadata i16 %call, metadata !8, metadata !16),
!dbg !17
 tail call void @h(i16 %call) #2, !dbg !18
 ret void, !dbg !19
}

For the second call, the AArch64 ISel lowering produces a 32-bit CopyFromReg
from w0.

 t18: ch,glue = AArch64ISD::CALL t15, TargetGlobalAddress:i64<i16 (...)*
@g> 0, RegisterMask:Untyped, test.c:5:11
 t19: ch,glue = callseq_end t18, TargetConstant:i64<0>,
TargetConstant:i64<0>, t18:1, test.c:5:11
 t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11

Then, TargetLowering::LowerCallTo adds a truncate node since the function return
type is i16.

t21: i16 = truncate t20, test.c:5:11

When lowering the dbg.value intrinsic, a SDDbgValue node is attached to the
truncate since it is the final result of the call.

Lowering the third call constructs any_extend(t21) for the 32-bit register type
but optimizes out the truncate node by the following code, and it seems that the
DbgValue node on the truncate is also lost.

Without having looked at this in more detail: there is a facility called
salvageDebugInfo that is supposed to be called on instructions and SDag nodes
right before they are deleted and it attempts to attach the debug info of the
dying node to another node in situations where this is possible and correct.

-- adrian

SelectionDAG::getNode(...)
...
   // (ext (trunx x)) -> x
   if (OpOpcode == ISD::TRUNCATE) {
     SDValue OpOp = Operand.getOperand(0);
     if (OpOp.getValueType() == VT)
       return OpOp;
   }

I am wondering if we can just transfer the dbg node here or we can have a better
solution.

The entire test file is here:

; ModuleID = 'test.ll'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx"

; Function Attrs: nounwind ssp uwtable
define void @f() #0 !dbg !4 {
entry:
 tail call void @h(i16 0) #2, !dbg !14
 %call = tail call i16 (...) @g() #2, !dbg !15
 tail call void @llvm.dbg.value(metadata i16 %call, metadata !8, metadata !16),
!dbg !17
 tail call void @h(i16 %call) #2, !dbg !18
 ret void, !dbg !19
}

declare void @h(i16)

declare i16 @g(...)

; Function Attrs: nounwind readnone
declare void @llvm.dbg.value(metadata, metadata, metadata) #1

attributes #0 = { nounwind ssp uwtable
"no-frame-pointer-elim"="true" }
attributes #1 = { nounwind readnone }
attributes #2 = { nounwind }

!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!10, !11, !12}
!llvm.ident = !{!13}

!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer:
"clang version 3.9.0 ", isOptimized: true, runtimeVersion: 0,
emissionKind: FullDebug, enums: !2)
!1 = !DIFile(filename: "test.c", directory:
"/Volumes/Data/llvm")
!2 = !{}
!4 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 3,
type: !5, isLocal: false, isDefinition: true, scopeLine: 3, isOptimized: true,
unit: !0, variables: !7)
!5 = !DISubroutineType(types: !6)
!6 = !{null}
!7 = !{!8}
!8 = !DILocalVariable(name: "a", scope: !4, file: !1, line: 5, type:
!9)
!9 = !DIBasicType(name: "int", size: 32, align: 32, encoding:
DW_ATE_signed)
!10 = !{i32 2, !"Dwarf Version", i32 2}
!11 = !{i32 2, !"Debug Info Version", i32 3}
!12 = !{i32 1, !"PIC Level", i32 2}
!13 = !{!"clang version 3.9.0 "}
!14 = !DILocation(line: 4, column: 3, scope: !4)
!15 = !DILocation(line: 5, column: 11, scope: !4)
!16 = !DIExpression()
!17 = !DILocation(line: 5, column: 7, scope: !4)
!18 = !DILocation(line: 6, column: 3, scope: !4)
!19 = !DILocation(line: 7, column: 1, scope: !4)

Thanks,
Sejong

-----Original Message-----
From: jdevlieghere at apple.com<mailto:jdevlieghere at apple.com>
<jdevlieghere at apple.com<mailto:jdevlieghere at apple.com>>
Sent: Thursday, March 15, 2018 8:43 AM
To: Se Jong Oh <sejooh at microsoft.com<mailto:sejooh at
microsoft.com>>
Cc: Vedant Kumar <vsk at apple.com<mailto:vsk at apple.com>>;
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Adrian
Prantl <aprantl at apple.com<mailto:aprantl at apple.com>>;
pidgeot18 at gmail.com<mailto:pidgeot18 at gmail.com>
Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at
microsoft.com<mailto:sejooh at microsoft.com>> wrote:

Hi Jonas,

Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by
producing DEBUG_VALUEs correctly. I also tried a simple function with few
operations and confirmed DEBUG_VALUEs which are not produced without
trasferDbgValues in SetPromotedInteger.

That’s great news! Do you plan on creating a patch for this upstream?

Thanks,
Sejong

From: jdevlieghere at apple.com<mailto:jdevlieghere at apple.com>
<jdevlieghere at apple.com<mailto:jdevlieghere at apple.com>>
Sent: Wednesday, March 14, 2018 4:07 AM
To: Se Jong Oh <sejooh at microsoft.com<mailto:sejooh at
microsoft.com>>
Cc: Vedant Kumar <vsk at apple.com<mailto:vsk at apple.com>>;
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Adrian
Prantl <aprantl at apple.com<mailto:aprantl at apple.com>>;
pidgeot18 at gmail.com<mailto:pidgeot18 at gmail.com>
Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

Hi Sejong,

Indeed, I think you are right and we should call transferDbgValues in
SetPromotedInteger.

I couldn’t immediately find a suitable in-tree test to verify this though. Can
you check and let me know whether this works for your target?

Thanks,
Jonas

On Mar 13, 2018, at 7:45 PM, Se Jong Oh <sejooh at
microsoft.com<mailto:sejooh at microsoft.com>> wrote:

Thanks for help! I think that sign extension is not involved here.
PromoteIntegerResult is called since i32 is not a legal type in my target and
the legalizer promotes operations with i32 result type to i64 operations. I
think that SetPromotedInteger seems to be a common place for all promotions like
SetExpandedInteger.

Jonas, I would appreciate it if you can guide me about whether my understanding
is correct or not.

Thanks,
Sejong

From: vsk at apple.com<mailto:vsk at apple.com> <vsk at
apple.com<mailto:vsk at apple.com>>
Sent: Friday, March 9, 2018 3:19 PM
To: Se Jong Oh <sejooh at microsoft.com<mailto:sejooh at
microsoft.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Jonas
Devlieghere <jdevlieghere at apple.com<mailto:jdevlieghere at
apple.com>>; Adrian Prantl <aprantl at apple.com<mailto:aprantl at
apple.com>>; pidgeot18 at gmail.com<mailto:pidgeot18 at gmail.com>
Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

+ Adrian, Joshua
+ Jonas, since he contributed the transferDbgValues change in
DAGTypeLegalizer::SetExpandedInteger

On Mar 8, 2018, at 5:44 PM, Se Jong Oh via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi,

I have a problem that dbg_value nodes are not transferred when integer DAG nodes
are promoted. For example, an i32 add node is promoted to a i64 add node by
DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not transferred
to the new node.

t9: i32 = add nsw t5, t8 à  t31: i64 = add t30, t7   ; the dbg_value node is not
transferred to the new i64 add node.

For expansion, DAGTypeLegalizer::SetExpandedInteger calls transferDbgValues()
but I couldn’t find any place to call trasnferDbgValues() for integer type
promotion in DAGTypeLegalizer ::SetPromotedInteger and other places.

Maybe the right place to do this is within the PromoteIntRes_ helper for sign
extensions?

best,
vedant

I am wondering If I miss anything or the legalization needs to call
transferDbgValues() for this case.

I found this problem because a recently added unittest,
DebugInfo/X86/linear-dbg-value.ll fails for my project, and the x86 and aarch64
backends don’t have this problem since they don’t promote i32 add nodes.

Thanks,
Sejong

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Csejooh%40microsoft.com%7C1334821c889d440e50ae08d58a8b6a62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567253755049370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=dmkgOHDLY6YWx1SISIdOg8a%2BC5hpT3mITrZZGwV715E%3D&reserved=0

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/2d77833a/attachment.html>

Adrian Prantl via llvm-dev

2018-Apr-30 21:58 UTC

head link

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

> On Apr 30, 2018, at 2:57 PM, Se Jong Oh <sejooh at microsoft.com>
wrote:
> 
> Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition
with constant.
You can look at llvm::salvageDebugInfo() for examples on how to handle other
situations.

-- adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/44cf4c7c/attachment.html>

Reasonably Related Threads

Search for more reasonably related threads

llvm dev - Apr 2018 - [SelectionDAG] DbgValue nodes aren't transferred

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

[llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred

Reasonably Related Threads