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/switch.cpp

113 lines
4.4 KiB
C++
Raw Normal View History

[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only -std=c++1z -triple %itanium_abi_triple -main-file-name switch.cpp %s | FileCheck %s
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
// CHECK: foo
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
void foo(int i) { // CHECK-NEXT: File 0, [[@LINE]]:17 -> [[@LINE+8]]:2 = #0
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch(i) {
[coverage] Make smaller regions for the first case of a switch. We never overwrite the end location of a region, so we would end up with an overly large region when we reused the switch's region. It's possible this code will be substantially rewritten in the near future to deal with fallthrough more accurately, but this seems like an improvement on its own for now. Differential Revision: https://reviews.llvm.org/D34801 llvm-svn: 309901
2017-08-03 07:22:50 +08:00
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:11 = #2
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
return;
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
case 2: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #3
[Coverage] Precise region termination with deferred regions (reapply) The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang This is a reapplication but there are no changes from the original commit. With D36813, the segment builder in llvm will be able to handle deferred regions correctly. llvm-svn: 312818
2017-09-09 02:44:56 +08:00
break; // CHECK-NEXT: File 0, [[@LINE]]:10 -> [[@LINE+2]]:3 = #1
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
}
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
int x = 0; // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2 = #1
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
}
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
int nop() { return 0; }
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: bar
void bar(int i) { // CHECK-NEXT: File 0, [[@LINE]]:17 -> [[@LINE+20]]:2 = #0
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch (i)
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 0, [[@LINE]]:5 -> [[@LINE]]:6 = 0
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch (i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+16]]:2 = #1
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
}
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch (i) // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+13]]:2 = #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
nop(); // CHECK-NEXT: File 0, [[@LINE]]:5 -> [[@LINE]]:10 = 0
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch (i) // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+10]]:2 = #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
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #5
nop();
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch (i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+6]]:2 = #4
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
nop(); // CHECK-NEXT: File 0, [[@LINE]]:5 -> [[@LINE+2]]:10 = 0
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #7
nop();
}
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
nop(); // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2 = #6
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
}
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
// CHECK: baz
void baz() { // CHECK-NEXT: File 0, [[@LINE]]:12 -> [[@LINE+5]]:2 = #0
switch (int i = true ? nop() // CHECK-NEXT: [[@LINE]]:26 -> [[@LINE]]:31 = #2
: nop(); // CHECK-NEXT: [[@LINE]]:26 -> [[@LINE]]:31 = (#0 - #2)
i) {}
nop(); // CHECK-NEXT: [[@LINE]]:3 -> [[@LINE+1]]:2 = #1
}
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
// CHECK-NEXT: main
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
int main() { // CHECK-NEXT: File 0, [[@LINE]]:12 -> [[@LINE+35]]:2 = #0
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
int i = 0;
[Coverage] The coverage region for switch covers the code after the switch. This patch fixes a regression introduced in r262697 that changed the way the coverage regions for switches are constructed. The PGO instrumentation counter for a switch statement refers to the counter at the exit of the switch. Therefore, the coverage region for the switch statement should cover the code that comes after the switch, and not the switch statement itself. rdar://28480997 Differential Revision: https://reviews.llvm.org/D24981 llvm-svn: 282554
2016-09-28 07:30:36 +08:00
switch(i) {
[coverage] Make smaller regions for the first case of a switch. We never overwrite the end location of a region, so we would end up with an overly large region when we reused the switch's region. It's possible this code will be substantially rewritten in the near future to deal with fallthrough more accurately, but this seems like an improvement on its own for now. Differential Revision: https://reviews.llvm.org/D34801 llvm-svn: 309901
2017-08-03 07:22:50 +08:00
case 0: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = #2
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 1;
break;
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = #3
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 2;
break;
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
default: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #4
[Coverage] Precise region termination with deferred regions (reapply) The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang This is a reapplication but there are no changes from the original commit. With D36813, the segment builder in llvm will be able to handle deferred regions correctly. llvm-svn: 312818
2017-09-09 02:44:56 +08:00
break; // CHECK-NEXT: File 0, [[@LINE]]:10 -> [[@LINE+2]]:3 = #1
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
}
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+23]]:2 = #1
[coverage] Make smaller regions for the first case of a switch. We never overwrite the end location of a region, so we would end up with an overly large region when we reused the switch's region. It's possible this code will be substantially rewritten in the near future to deal with fallthrough more accurately, but this seems like an improvement on its own for now. Differential Revision: https://reviews.llvm.org/D34801 llvm-svn: 309901
2017-08-03 07:22:50 +08:00
case 0: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = #6
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 1;
break;
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
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+3]]:10 = #7
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 2;
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
default: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = (#7 + #8)
[Coverage] Precise region termination with deferred regions (reapply) The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang This is a reapplication but there are no changes from the original commit. With D36813, the segment builder in llvm will be able to handle deferred regions correctly. llvm-svn: 312818
2017-09-09 02:44:56 +08:00
break; // CHECK-NEXT: File 0, [[@LINE]]:10 -> [[@LINE+3]]:3 = #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
}
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+13]]:2 = #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
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+5]]:11 = #10
case 2: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+4]]:11 = (#10 + #11)
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 11;
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
case 3: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:11 = ((#10 + #11) + #12)
InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't used llvm-svn: 228035
2015-02-04 05:35:49 +08:00
case 4: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:11 = (((#10 + #11) + #12) + #13)
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
i = 99;
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
}
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
foo(1); // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+3]]:11 = #9
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
bar(1);
[Coverage] Support for C++17 switch initializers Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
2016-10-15 07:38:13 +08:00
baz();
Add tests for coverage mapping generation. This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
2014-08-20 01:32:30 +08:00
return 0;
}
[coverage] Make smaller regions for the first case of a switch. We never overwrite the end location of a region, so we would end up with an overly large region when we reused the switch's region. It's possible this code will be substantially rewritten in the near future to deal with fallthrough more accurately, but this seems like an improvement on its own for now. Differential Revision: https://reviews.llvm.org/D34801 llvm-svn: 309901
2017-08-03 07:22:50 +08:00
// FIXME: End location for "case 1" shouldn't point at the end of the switch.
// CHECK: fallthrough
int fallthrough(int i) { // CHECK-NEXT: File 0, [[@LINE]]:24 -> [[@LINE+12]]:2 = #0
switch(i) {
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+8]]:10 = #2
i = 23;
case 2: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = (#2 + #3)
i = 11;
break;
case 3: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+3]]:10 = #4
case 4: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = (#4 + #5)
i = 99;
break;
}
}
[coverage] Special-case calls to noreturn functions. The code after a noreturn call doesn't execute. The pattern in the testcase is pretty common in LLVM (a switch with a default case that calls llvm_unreachable). The original version of this patch was reverted in r309995 due to a crash. This version includes a fix for that crash (testcase in test/CoverageMapping/md.cpp). Differential Revision: https://reviews.llvm.org/D36250 llvm-svn: 310406
2017-08-09 04:10:14 +08:00
void abort(void) __attribute((noreturn));
// CHECK: noret
int noret(int x) { // CHECK-NEXT: File 0, [[@LINE]]:18 -> [[@LINE+9]]:2
switch (x) {
default: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:12
abort();
case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:13
return 5;
case 2: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:14
return 10;
}
}