maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CoverageMapping/macroscopes.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

129 lines
4.3 KiB
C++
Raw Normal View History

[PGO] cc1 option name change for profile instrumentation This patch changes cc1 option -fprofile-instr-generate to an enum option -fprofile-instrument={clang|none}. It also changes cc1 options -fprofile-instr-generate= to -fprofile-instrument-path=. The driver level option -fprofile-instr-generate and -fprofile-instr-generate= remain intact. This change will pave the way to integrate new PGO instrumentation in IR level. Review: http://reviews.llvm.org/D16730 llvm-svn: 259811
2016-02-05 02:39:09 +08:00
// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only -main-file-name macroscopes.cpp %s | FileCheck %s
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
#define starts_a_scope for (int i = 0; i < 2; ++i) {
#define ends_a_scope \
x = x; \
}
#define some_code \
x = x; \
if (x == 0) { \
x = 1; \
} else { \
x = 2; \
} \
if (true) { \
x = x; \
} else { \
x = x; \
}
#define starts_a_while while (x < 5)
#define simple_stmt ++x
[Coverage] Fix an issue where a coverage region might not be created for a macro containing a loop statement. The issue happened when a macro contained a full for or while statement, which body ended at the end of the macro. Differential Revision: http://reviews.llvm.org/D19725 llvm-svn: 268511
2016-05-04 23:38:26 +08:00
#define macro_with_for \
x = 3; \
for (int i = 0; i < x; ++i) { \
}
#define macro_with_while \
x = 4; \
while (x < 5) { \
++x; \
}
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK: main
// CHECK-NEXT: File 0, [[@LINE+1]]:12 -> {{[0-9]+}}:2 = #0
int main() {
int x = 0;
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:3 -> [[@LINE+2]]:17 = #0
// CHECK-NEXT: File 0, [[@LINE+1]]:17 -> [[@LINE+7]]:15 = #1
starts_a_scope
x = x;
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:5 -> [[@LINE+1]]:14 = #1
some_code
x = x;
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:3 -> [[@LINE+1]]:15 = #1
ends_a_scope
// CHECK-NEXT: Expansion,File 0, [[@LINE+4]]:3 -> [[@LINE+4]]:17 = #0
// CHECK-NEXT: File 0, [[@LINE+3]]:17 -> [[@LINE+5]]:15 = #4
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:5 -> [[@LINE+3]]:14 = #4
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:3 -> [[@LINE+3]]:15 = #4
starts_a_scope
some_code
ends_a_scope
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:3 -> [[@LINE+3]]:17 = #0
// CHECK-NEXT: File 0, [[@LINE+2]]:17 -> [[@LINE+3]]:15 = #7
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:3 -> [[@LINE+2]]:15 = #7
starts_a_scope
ends_a_scope
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:3 -> [[@LINE+2]]:17 = #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:5 -> [[@LINE+2]]:16 = #8
starts_a_while
simple_stmt;
x = 0;
// CHECK-NEXT: Expansion,File 0, [[@LINE+4]]:3 -> [[@LINE+4]]:17 = #0
// CHECK-NEXT: File 0, [[@LINE+3]]:18 -> [[@LINE+5]]:15 = #9
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:5 -> [[@LINE+3]]:16 = #9
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:3 -> [[@LINE+3]]:15 = #9
starts_a_while {
simple_stmt;
ends_a_scope
[Coverage] Fix an issue where a coverage region might not be created for a macro containing a loop statement. The issue happened when a macro contained a full for or while statement, which body ended at the end of the macro. Differential Revision: http://reviews.llvm.org/D19725 llvm-svn: 268511
2016-05-04 23:38:26 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:3 -> [[@LINE+1]]:17 = #0
macro_with_for
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:3 -> [[@LINE+1]]:19 = #0
macro_with_while
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
return 0;
}
// CHECK-NEXT: File 1, 3:24 -> 3:53 = #0
// CHECK-NEXT: File 1, 3:40 -> 3:45 = (#0 + #1)
// CHECK-NEXT: File 1, 3:47 -> 3:50 = #1
// CHECK-NEXT: File 1, 3:52 -> 3:53 = #1
// CHECK-NEXT: File 2, 10:3 -> 20:4 = #1
InstrProf: Always emit a coverage region for the condition of an if When tools like llvm-cov show regions, it's much easier to understand what's happening if the condition of an if shows a counter as well as the body. llvm-svn: 229813
2015-02-19 11:10:30 +08:00
// CHECK-NEXT: File 2, 11:7 -> 11:13 = #1
[Coverage] Emit a gap area after if conditions The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758
2017-11-09 10:33:38 +08:00
// CHECK: File 2, 11:15 -> 13:4 = #2
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 2, 13:10 -> 15:4 = (#1 - #2)
InstrProf: Always emit a coverage region for the condition of an if When tools like llvm-cov show regions, it's much easier to understand what's happening if the condition of an if shows a counter as well as the body. llvm-svn: 229813
2015-02-19 11:10:30 +08:00
// CHECK-NEXT: File 2, 16:7 -> 16:11 = #1
[Coverage] Emit a gap area after if conditions The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758
2017-11-09 10:33:38 +08:00
// CHECK: File 2, 16:13 -> 18:4 = #3
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 2, 18:10 -> 20:4 = (#1 - #3)
// CHECK-NEXT: File 3, 6:3 -> 7:4 = #1
// CHECK-NEXT: File 4, 3:24 -> 3:53 = #0
// CHECK-NEXT: File 4, 3:40 -> 3:45 = (#0 + #4)
// CHECK-NEXT: File 4, 3:47 -> 3:50 = #4
// CHECK-NEXT: File 4, 3:52 -> 3:53 = #4
// CHECK-NEXT: File 5, 10:3 -> 20:4 = #4
InstrProf: Always emit a coverage region for the condition of an if When tools like llvm-cov show regions, it's much easier to understand what's happening if the condition of an if shows a counter as well as the body. llvm-svn: 229813
2015-02-19 11:10:30 +08:00
// CHECK-NEXT: File 5, 11:7 -> 11:13 = #4
[Coverage] Emit a gap area after if conditions The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758
2017-11-09 10:33:38 +08:00
// CHECK: File 5, 11:15 -> 13:4 = #5
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 5, 13:10 -> 15:4 = (#4 - #5)
InstrProf: Always emit a coverage region for the condition of an if When tools like llvm-cov show regions, it's much easier to understand what's happening if the condition of an if shows a counter as well as the body. llvm-svn: 229813
2015-02-19 11:10:30 +08:00
// CHECK-NEXT: File 5, 16:7 -> 16:11 = #4
[Coverage] Emit a gap area after if conditions The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758
2017-11-09 10:33:38 +08:00
// CHECK: File 5, 16:13 -> 18:4 = #6
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 5, 18:10 -> 20:4 = (#4 - #6)
// CHECK-NEXT: File 6, 6:3 -> 7:4 = #4
// CHECK-NEXT: File 7, 3:24 -> 3:53 = #0
// CHECK-NEXT: File 7, 3:40 -> 3:45 = (#0 + #7)
// CHECK-NEXT: File 7, 3:47 -> 3:50 = #7
// CHECK-NEXT: File 7, 3:52 -> 3:53 = #7
// CHECK-NEXT: File 8, 6:3 -> 7:4 = #7
// CHECK-NEXT: File 9, 22:24 -> 22:37 = #0
// CHECK-NEXT: File 9, 22:31 -> 22:36 = (#0 + #8)
// CHECK-NEXT: File 10, 23:21 -> 23:24 = #8
// CHECK-NEXT: File 11, 22:24 -> 22:37 = #0
// CHECK-NEXT: File 11, 22:31 -> 22:36 = (#0 + #9)
// CHECK-NEXT: File 12, 23:21 -> 23:24 = #9
// CHECK-NEXT: File 13, 6:3 -> 7:4 = #9
[Coverage] Fix an issue where a coverage region might not be created for a macro containing a loop statement. The issue happened when a macro contained a full for or while statement, which body ended at the end of the macro. Differential Revision: http://reviews.llvm.org/D19725 llvm-svn: 268511
2016-05-04 23:38:26 +08:00
// CHECK-NEXT: File 14, 26:3 -> 28:4 = #0
// CHECK-NEXT: File 14, 27:19 -> 27:24 = (#0 + #10)
// CHECK-NEXT: File 14, 27:26 -> 27:29 = #10
// CHECK-NEXT: File 14, 27:31 -> 28:4 = #10
// CHECK-NEXT: File 15, 31:3 -> 34:4 = #0
// CHECK-NEXT: File 15, 32:10 -> 32:15 = (#0 + #11)
// CHECK-NEXT: File 15, 32:17 -> 34:4 = #11