maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/AArch64/inlined-argument.ll

153 lines
7.9 KiB
LLVM
Raw Normal View History

Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
; RUN: llc -filetype=obj -o - %s | llvm-dwarfdump --name resource - | FileCheck %s
; CHECK: DW_TAG_formal_parameter
; CHECK: DW_TAG_formal_parameter
; CHECK-NEXT: DW_AT_location (DW_OP_reg1 W1)
; CHECK-NEXT: DW_AT_abstract_origin {{.*}}"resource"
;
[DebugInfo] Terminate all location-lists at end of block This commit reapplies r359426 (which was reverted in r360301 due to performance problems) and rolls in D61940 to address the performance problem. I've combined the two to avoid creating a span of slow-performance, and to ease reverting if more problems crop up. The summary of D61940: This patch removes the "ChangingRegs" facility in DbgEntityHistoryCalculator, as its overapproximate nature can produce incorrect variable locations. An unchanging register doesn't mean a variable doesn't change its location. The patch kills off everything that calculates the ChangingRegs vector. Previously ChangingRegs spotted epilogues and marked registers as unchanging if they weren't modified outside the epilogue, increasing the chance that we can emit a single-location variable record. Without this feature, debug-loc-offset.mir and pr19307.mir become temporarily XFAIL. They'll be re-enabled by D62314, using the FrameDestroy flag to identify epilogues, I've split this into two steps as FrameDestroy isn't necessarily supported by all backends. The logic for terminating variable locations at the end of a basic block now becomes much more enjoyably simple: we just terminate them all. Other test changes: inlined-argument.ll becomes XFAIL, but for a longer term. The current algorithm for detecting that a variable has a single-location doesn't work in this scenario (inlined function in multiple blocks), only other bugs were making this test work. fission-ranges.ll gets slightly refreshed too, as the location of "p" is now correctly determined to be a single location. Differential Revision: https://reviews.llvm.org/D61940 llvm-svn: 362951
2019-06-10 23:23:46 +08:00
; XFAIL: *
; This test now fails as it requires the single-location variable recognizer
; to spot that the inlined function goes out of scope before the 'find.exit'
; exit block. Previously, unchanging variable locations could be extended to
; the end of the function, often erronously, and that's why this test used to
; pass.
; A future algorithm _should_ be able to recognize that "resource"/!37 covers
; all blocks in its lexical scope.
;
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
; Generated from:
; typedef struct t *t_t;
; extern unsigned int enable;
; struct t {
; struct q {
; struct q *next;
; unsigned long long resource;
; } * s;
; } * tt;
; static unsigned long find(t_t t, unsigned long long resource) {
; struct q *q;
; q = t->s;
; while (q) {
; if (q->resource == resource)
; return q;
; q = q->next;
; }
; }
; int g(t_t t, unsigned long long r) {
; struct q *q;
; q = find(t, r);
; if (!q)
; if (__builtin_expect(enable, 0)) { }
; }
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
; ModuleID = 'inlined-arg.c'
source_filename = "inlined-arg.c"
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-ios5.0.0"
%struct.t = type { %struct.q* }
%struct.q = type { %struct.q*, i64 }
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
@tt = common local_unnamed_addr global %struct.t* null, align 8, !dbg !0
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
; Function Attrs: norecurse nounwind readonly ssp uwtable
define i32 @g(%struct.t* nocapture readonly %t, i64 %r) local_unnamed_addr !dbg !21 {
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
entry:
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
call void @llvm.dbg.value(metadata %struct.t* %t, metadata !27, metadata !DIExpression()), !dbg !30
call void @llvm.dbg.value(metadata i64 %r, metadata !28, metadata !DIExpression()), !dbg !31
call void @llvm.dbg.value(metadata %struct.t* %t, metadata !32, metadata !DIExpression()), !dbg !39
call void @llvm.dbg.value(metadata i64 %r, metadata !37, metadata !DIExpression()), !dbg !41
%s.i = getelementptr inbounds %struct.t, %struct.t* %t, i64 0, i32 0, !dbg !42
%q.05.i = load %struct.q*, %struct.q** %s.i, align 8, !dbg !43, !tbaa !44
call void @llvm.dbg.value(metadata %struct.q* %q.05.i, metadata !38, metadata !DIExpression()), !dbg !48
%tobool6.i = icmp eq %struct.q* %q.05.i, null, !dbg !49
br i1 %tobool6.i, label %find.exit, label %while.body.i, !dbg !49
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
while.body.i: ; preds = %entry, %if.end.i
%q.07.i = phi %struct.q* [ %q.0.i, %if.end.i ], [ %q.05.i, %entry ]
%resource1.i = getelementptr inbounds %struct.q, %struct.q* %q.07.i, i64 0, i32 1, !dbg !50
%0 = load i64, i64* %resource1.i, align 8, !dbg !50, !tbaa !53
%cmp.i = icmp eq i64 %0, %r, !dbg !56
br i1 %cmp.i, label %find.exit, label %if.end.i, !dbg !57
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
if.end.i: ; preds = %while.body.i
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
%next.i = getelementptr inbounds %struct.q, %struct.q* %q.07.i, i64 0, i32 0, !dbg !58
%q.0.i = load %struct.q*, %struct.q** %next.i, align 8, !dbg !43, !tbaa !44
call void @llvm.dbg.value(metadata %struct.q* %q.0.i, metadata !38, metadata !DIExpression()), !dbg !48
%tobool.i = icmp eq %struct.q* %q.0.i, null, !dbg !49
br i1 %tobool.i, label %find.exit, label %while.body.i, !dbg !49, !llvm.loop !59
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
find.exit: ; preds = %while.body.i, %if.end.i, %entry
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
call void @llvm.dbg.value(metadata %struct.q* undef, metadata !29, metadata !DIExpression()), !dbg !61
ret i32 undef, !dbg !62
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
}
; Function Attrs: nounwind readnone speculatable
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
declare void @llvm.dbg.value(metadata, metadata, metadata)
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
!llvm.dbg.cu = !{!2}
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
!llvm.module.flags = !{!16, !17, !18, !19}
!llvm.ident = !{!20}
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = distinct !DIGlobalVariable(name: "tt", scope: !2, file: !3, line: 8, type: !6, isLocal: false, isDefinition: true)
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 9.0.0 (https://github.com/llvm/llvm-project.git cd3671d5dabc8848619d872f994770167a44ac5a)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, nameTableKind: GNU)
!3 = !DIFile(filename: "inlined-arg.c", directory: "")
Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue(). In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
2017-11-09 02:27:13 +08:00
!4 = !{}
!5 = !{!0}
!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64)
!7 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "t", file: !3, line: 3, size: 64, elements: !8)
!8 = !{!9}
!9 = !DIDerivedType(tag: DW_TAG_member, name: "s", scope: !7, file: !3, line: 7, baseType: !10, size: 64)
!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
!11 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "q", file: !3, line: 4, size: 128, elements: !12)
!12 = !{!13, !14}
!13 = !DIDerivedType(tag: DW_TAG_member, name: "next", scope: !11, file: !3, line: 5, baseType: !10, size: 64)
!14 = !DIDerivedType(tag: DW_TAG_member, name: "resource", scope: !11, file: !3, line: 6, baseType: !15, size: 64, offset: 64)
!15 = !DIBasicType(name: "long long unsigned int", size: 64, encoding: DW_ATE_unsigned)
!16 = !{i32 2, !"Dwarf Version", i32 2}
!17 = !{i32 2, !"Debug Info Version", i32 3}
!18 = !{i32 1, !"wchar_size", i32 4}
[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
2019-06-19 18:50:47 +08:00
!19 = !{i32 7, !"PIC Level", i32 2}
!20 = !{!"clang version 9.0.0 (https://github.com/llvm/llvm-project.git cd3671d5dabc8848619d872f994770167a44ac5a)"}
!21 = distinct !DISubprogram(name: "g", scope: !3, file: !3, line: 19, type: !22, scopeLine: 19, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !26)
!22 = !DISubroutineType(types: !23)
!23 = !{!24, !25, !15}
!24 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!25 = !DIDerivedType(tag: DW_TAG_typedef, name: "t_t", file: !3, line: 1, baseType: !6)
!26 = !{!27, !28, !29}
!27 = !DILocalVariable(name: "t", arg: 1, scope: !21, file: !3, line: 19, type: !25)
!28 = !DILocalVariable(name: "r", arg: 2, scope: !21, file: !3, line: 19, type: !15)
!29 = !DILocalVariable(name: "q", scope: !21, file: !3, line: 20, type: !10)
!30 = !DILocation(line: 19, column: 11, scope: !21)
!31 = !DILocation(line: 19, column: 33, scope: !21)
!32 = !DILocalVariable(name: "t", arg: 1, scope: !33, file: !3, line: 10, type: !25)
!33 = distinct !DISubprogram(name: "find", scope: !3, file: !3, line: 10, type: !34, scopeLine: 10, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !36)
!34 = !DISubroutineType(types: !35)
!35 = !{!10, !25, !15}
!36 = !{!32, !37, !38}
!37 = !DILocalVariable(name: "resource", arg: 2, scope: !33, file: !3, line: 10, type: !15)
!38 = !DILocalVariable(name: "q", scope: !33, file: !3, line: 11, type: !10)
!39 = !DILocation(line: 10, column: 27, scope: !33, inlinedAt: !40)
!40 = distinct !DILocation(line: 21, column: 7, scope: !21)
!41 = !DILocation(line: 10, column: 49, scope: !33, inlinedAt: !40)
!42 = !DILocation(line: 12, column: 10, scope: !33, inlinedAt: !40)
!43 = !DILocation(line: 0, scope: !33, inlinedAt: !40)
!44 = !{!45, !45, i64 0}
!45 = !{!"any pointer", !46, i64 0}
!46 = !{!"omnipotent char", !47, i64 0}
!47 = !{!"Simple C/C++ TBAA"}
!48 = !DILocation(line: 11, column: 13, scope: !33, inlinedAt: !40)
!49 = !DILocation(line: 13, column: 3, scope: !33, inlinedAt: !40)
!50 = !DILocation(line: 14, column: 12, scope: !51, inlinedAt: !40)
!51 = distinct !DILexicalBlock(scope: !52, file: !3, line: 14, column: 9)
!52 = distinct !DILexicalBlock(scope: !33, file: !3, line: 13, column: 13)
!53 = !{!54, !55, i64 8}
!54 = !{!"q", !45, i64 0, !55, i64 8}
!55 = !{!"long long", !46, i64 0}
!56 = !DILocation(line: 14, column: 21, scope: !51, inlinedAt: !40)
!57 = !DILocation(line: 14, column: 9, scope: !52, inlinedAt: !40)
!58 = !DILocation(line: 16, column: 12, scope: !52, inlinedAt: !40)
!59 = distinct !{!59, !49, !60}
!60 = !DILocation(line: 17, column: 3, scope: !33, inlinedAt: !40)
!61 = !DILocation(line: 20, column: 13, scope: !21)
!62 = !DILocation(line: 24, column: 1, scope: !21)