maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/debug-info-line-if.cpp

68 lines
2.0 KiB
C++
Raw Normal View History

Stop messing with the 'g' group of options in CompilerInvocation. With this change, most 'g' options are rejected by CompilerInvocation. They remain only as Driver options. The new way to request debug info from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}" and "-dwarf-version={2|3|4}". In the absence of a command-line option to specify Dwarf version, the Toolchain decides it, rather than placing Toolchain-specific logic in CompilerInvocation. Also fix a bug in the Windows compatibility argument parsing in which the "rightmost argument wins" principle failed. Differential Revision: http://reviews.llvm.org/D13221 llvm-svn: 249655
2015-10-08 12:24:12 +08:00
// RUN: %clang_cc1 -debug-info-kind=limited -std=c++11 -S -emit-llvm %s -o - | FileCheck %s
Debug Info: Fix the source range for IfStmt's ConditionScope. Since the continuation block of the if statement is emitted within the condition scope this had the undesirable effect of creating a line table entry at the end of the then or else statement, a line that may have never been executed. PR19864 / rdar://problem/17052973 llvm-svn: 209764
2014-05-29 03:10:59 +08:00
// PR19864
DebugInfo: While loop backedge should be attribute to the start of the while statement. A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864) llvm-svn: 215768
2014-08-16 05:11:25 +08:00
extern int v[2];
int a = 0, b = 0;
Debug Info: Fix the source range for IfStmt's ConditionScope. Since the continuation block of the if statement is emitted within the condition scope this had the undesirable effect of creating a line table entry at the end of the then or else statement, a line that may have never been executed. PR19864 / rdar://problem/17052973 llvm-svn: 209764
2014-05-29 03:10:59 +08:00
int main() {
DebugInfo: While loop backedge should be attribute to the start of the while statement. A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864) llvm-svn: 215768
2014-08-16 05:11:25 +08:00
#line 100
for (int x : v)
if (x)
++b; // CHECK: add nsw{{.*}}, 1
else
++a; // CHECK: add nsw{{.*}}, 1
// The continuation block if the if statement should not share the
// location of the ++a statement. The branch back to the start of the loop
// should be attributed to the loop header line.
Debug Info: Fix the source range for IfStmt's ConditionScope. Since the continuation block of the if statement is emitted within the condition scope this had the undesirable effect of creating a line table entry at the end of the then or else statement, a line that may have never been executed. PR19864 / rdar://problem/17052973 llvm-svn: 209764
2014-05-29 03:10:59 +08:00
DebugInfo: While loop backedge should be attribute to the start of the while statement. A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864) llvm-svn: 215768
2014-08-16 05:11:25 +08:00
// CHECK: br label
// CHECK: br label
Add a loop's debug location to its llvm.loop metadata Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was an inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. When emitting debug information, this commit causes us to add the debug location as an operand to each loop's llvm.loop metadata. Thus, we now generate this metadata for all loops (not just loops with optimization hints) when we're otherwise generating debug information. The remark test case changes depend on the companion LLVM commit r270771. llvm-svn: 270772
2016-05-26 05:53:24 +08:00
// CHECK: br label {{.*}}, !dbg [[DBG1:![0-9]*]], !llvm.loop [[L1:![0-9]*]]
Debug Info: Fix the source range for IfStmt's ConditionScope. Since the continuation block of the if statement is emitted within the condition scope this had the undesirable effect of creating a line table entry at the end of the then or else statement, a line that may have never been executed. PR19864 / rdar://problem/17052973 llvm-svn: 209764
2014-05-29 03:10:59 +08:00
DebugInfo: While loop backedge should be attribute to the start of the while statement. A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864) llvm-svn: 215768
2014-08-16 05:11:25 +08:00
#line 200
while (a)
if (b)
++b; // CHECK: add nsw{{.*}}, 1
else
++a; // CHECK: add nsw{{.*}}, 1
// CHECK: br label
Add a loop's debug location to its llvm.loop metadata Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was an inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. When emitting debug information, this commit causes us to add the debug location as an operand to each loop's llvm.loop metadata. Thus, we now generate this metadata for all loops (not just loops with optimization hints) when we're otherwise generating debug information. The remark test case changes depend on the companion LLVM commit r270771. llvm-svn: 270772
2016-05-26 05:53:24 +08:00
// CHECK: br label {{.*}}, !dbg [[DBG2:![0-9]*]], !llvm.loop [[L2:![0-9]*]]
DebugInfo: for loop backedge should be attributed to the start of the for statement. Similar to r215768 (which fixed the same case for while loops). To quote r215768's commit message: "A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864)" llvm-svn: 216297
2014-08-23 06:25:37 +08:00
#line 300
for (; a; )
if (b)
++b; // CHECK: add nsw{{.*}}, 1
else
++a; // CHECK: add nsw{{.*}}, 1
// CHECK: br label
Add a loop's debug location to its llvm.loop metadata Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was an inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. When emitting debug information, this commit causes us to add the debug location as an operand to each loop's llvm.loop metadata. Thus, we now generate this metadata for all loops (not just loops with optimization hints) when we're otherwise generating debug information. The remark test case changes depend on the companion LLVM commit r270771. llvm-svn: 270772
2016-05-26 05:53:24 +08:00
// CHECK: br label {{.*}}, !dbg [[DBG3:![0-9]*]], !llvm.loop [[L3:![0-9]*]]
DebugInfo: for loop backedge should be attributed to the start of the for statement. Similar to r215768 (which fixed the same case for while loops). To quote r215768's commit message: "A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864)" llvm-svn: 216297
2014-08-23 06:25:37 +08:00
DebugInfo: Test that the loop backedge in a range-for is attribute to the loop header. This already works, but somewhat by accident (due to the order of emission in clang, the location is set to the loop header (during the emission of the iteratior increment) before the loop backedge is emitted), so let's just add a test for symmetry and future-proofing. llvm-svn: 216298
2014-08-23 06:29:50 +08:00
#line 400
int x[] = {1, 2};
for (int y : x)
if (b)
++b; // CHECK: add nsw{{.*}}, 1
else
++a; // CHECK: add nsw{{.*}}, 1
// CHECK: br label
Add a loop's debug location to its llvm.loop metadata Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was an inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. When emitting debug information, this commit causes us to add the debug location as an operand to each loop's llvm.loop metadata. Thus, we now generate this metadata for all loops (not just loops with optimization hints) when we're otherwise generating debug information. The remark test case changes depend on the companion LLVM commit r270771. llvm-svn: 270772
2016-05-26 05:53:24 +08:00
// CHECK: br label {{.*}}, !dbg [[DBG4:![0-9]*]], !llvm.loop [[L4:![0-9]*]]
DebugInfo: Test that the loop backedge in a range-for is attribute to the loop header. This already works, but somewhat by accident (due to the order of emission in clang, the location is set to the loop header (during the emission of the iteratior increment) before the loop backedge is emitted), so let's just add a test for symmetry and future-proofing. llvm-svn: 216298
2014-08-23 06:29:50 +08:00
Add a loop's debug location to its llvm.loop metadata Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was an inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. When emitting debug information, this commit causes us to add the debug location as an operand to each loop's llvm.loop metadata. Thus, we now generate this metadata for all loops (not just loops with optimization hints) when we're otherwise generating debug information. The remark test case changes depend on the companion LLVM commit r270771. llvm-svn: 270772
2016-05-26 05:53:24 +08:00
// CHECK-DAG: [[DBG1]] = !DILocation(line: 100, scope: !{{.*}})
// CHECK-DAG: [[DBG2]] = !DILocation(line: 200, scope: !{{.*}})
// CHECK-DAG: [[DBG3]] = !DILocation(line: 300, scope: !{{.*}})
// CHECK-DAG: [[DBG4]] = !DILocation(line: 401, scope: !{{.*}})
// CHECK-DAG: [[L1]] = distinct !{[[L1]], [[LDBG1:![0-9]*]]}
// CHECK-DAG: [[LDBG1]] = !DILocation(line: 100, scope: !{{.*}})
// CHECK-DAG: [[L2]] = distinct !{[[L2]], [[LDBG2:![0-9]*]]}
// CHECK-DAG: [[LDBG2]] = !DILocation(line: 200, scope: !{{.*}})
// CHECK-DAG: [[L3]] = distinct !{[[L3]], [[LDBG3:![0-9]*]]}
// CHECK-DAG: [[LDBG3]] = !DILocation(line: 300, scope: !{{.*}})
// CHECK-DAG: [[L4]] = distinct !{[[L4]], [[LDBG4:![0-9]*]]}
// CHECK-DAG: [[LDBG4]] = !DILocation(line: 401, scope: !{{.*}})
Debug Info: Fix the source range for IfStmt's ConditionScope. Since the continuation block of the if statement is emitted within the condition scope this had the undesirable effect of creating a line table entry at the end of the then or else statement, a line that may have never been executed. PR19864 / rdar://problem/17052973 llvm-svn: 209764
2014-05-29 03:10:59 +08:00
}