2020-07-06 02:47:02 +08:00
|
|
|
// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info -std=c++11 -S -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
|
2014-05-29 03:10:59 +08:00
|
|
|
// PR19864
|
2014-08-16 05:11:25 +08:00
|
|
|
extern int v[2];
|
|
|
|
|
int a = 0, b = 0;
|
2014-05-29 03:10:59 +08:00
|
|
|
int main() {
|
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.
|
2014-05-29 03:10:59 +08:00
|
|
|
|
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]*]]
|
2014-05-29 03:10:59 +08:00
|
|
|
|
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]*]]
|
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]*]]
|
2014-08-23 06:25:37 +08:00
|
|
|
|
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]*]]
|
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: !{{.*}})
|
|
|
|
|
|
2016-11-10 22:44:30 +08:00
|
|
|
// CHECK-DAG: [[L1]] = distinct !{[[L1]], [[SLDBG1:![0-9]*]], [[ELDBG1:![0-9]*]]}
|
|
|
|
|
// CHECK-DAG: [[SLDBG1]] = !DILocation(line: 100, scope: !{{.*}})
|
|
|
|
|
// CHECK-DAG: [[ELDBG1]] = !DILocation(line: 104, scope: !{{.*}})
|
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
|
|
|
|
2016-11-10 22:44:30 +08:00
|
|
|
// CHECK-DAG: [[L2]] = distinct !{[[L2]], [[SLDBG2:![0-9]*]], [[ELDBG2:![0-9]*]]}
|
|
|
|
|
// CHECK-DAG: [[SLDBG2]] = !DILocation(line: 200, scope: !{{.*}})
|
|
|
|
|
// CHECK-DAG: [[ELDBG2]] = !DILocation(line: 204, scope: !{{.*}})
|
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
|
|
|
|
2016-11-10 22:44:30 +08:00
|
|
|
// CHECK-DAG: [[L3]] = distinct !{[[L3]], [[SLDBG3:![0-9]*]], [[ELDBG3:![0-9]*]]}
|
|
|
|
|
// CHECK-DAG: [[SLDBG3]] = !DILocation(line: 300, scope: !{{.*}})
|
|
|
|
|
// CHECK-DAG: [[ELDBG3]] = !DILocation(line: 304, scope: !{{.*}})
|
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
|
|
|
|
2016-11-10 22:44:30 +08:00
|
|
|
// CHECK-DAG: [[L4]] = distinct !{[[L4]], [[SLDBG4:![0-9]*]], [[ELDBG4:![0-9]*]]}
|
|
|
|
|
// CHECK-DAG: [[SLDBG4]] = !DILocation(line: 401, scope: !{{.*}})
|
|
|
|
|
// CHECK-DAG: [[ELDBG4]] = !DILocation(line: 405, scope: !{{.*}})
|
2014-05-29 03:10:59 +08:00
|
|
|
}
|