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/macroception.c

47 lines
1.6 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 macroception.c %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
#define M2 {
#define M1 M2
#define M22 }
#define M11 M22
InstrProf: Avoid repeated linear searches in a hot path When generating coverage regions, we were doing a linear search through the existing regions in order to try to merge related ones. Most of the time this would find what it was looking for in a small number of steps and it wasn't a big deal, but in cases with many regions and few mergeable ones this leads to an absurd compile time regression. This changes the coverage mapping logic to do a single sort and then merge as we go, which is a bit simpler and about 100 times faster. I've also added FIXMEs on a couple of behaviours that seem a little suspect, while keeping them behaving as they were - I'll look into these soon. The test changes here are mostly tedious reorganization, because the ordering of regions we output has become slightly (but not completely) more consistent from the almost completely arbitrary ordering we got before. llvm-svn: 218738
2014-10-01 11:33:52 +08:00
// CHECK-LABEL: main:
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: Expansion,File 0, [[@LINE+2]]:12 -> [[@LINE+2]]:14 = #0
// CHECK-NEXT: File 0, [[@LINE+1]]:14 -> [[@LINE+3]]:2 = #0
int main() M1
return 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
}
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: Expansion,File 1, 4:12 -> 4:14 = #0
// CHECK-NEXT: File 2, 3:12 -> 3:13 = #0
InstrProf: Avoid repeated linear searches in a hot path When generating coverage regions, we were doing a linear search through the existing regions in order to try to merge related ones. Most of the time this would find what it was looking for in a small number of steps and it wasn't a big deal, but in cases with many regions and few mergeable ones this leads to an absurd compile time regression. This changes the coverage mapping logic to do a single sort and then merge as we go, which is a bit simpler and about 100 times faster. I've also added FIXMEs on a couple of behaviours that seem a little suspect, while keeping them behaving as they were - I'll look into these soon. The test changes here are mostly tedious reorganization, because the ordering of regions we output has become slightly (but not completely) more consistent from the almost completely arbitrary ordering we got before. llvm-svn: 218738
2014-10-01 11:33:52 +08:00
// CHECK-LABEL: func2:
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+2]]:14 -> [[@LINE+4]]:4 = #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:1 -> [[@LINE+3]]:4 = #0
void func2() {
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 x = 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
M11
// CHECK-NEXT: Expansion,File 1, 6:13 -> 6:16 = #0
// CHECK-NEXT: File 2, 5:13 -> 5:14 = #0
InstrProf: Avoid repeated linear searches in a hot path When generating coverage regions, we were doing a linear search through the existing regions in order to try to merge related ones. Most of the time this would find what it was looking for in a small number of steps and it wasn't a big deal, but in cases with many regions and few mergeable ones this leads to an absurd compile time regression. This changes the coverage mapping logic to do a single sort and then merge as we go, which is a bit simpler and about 100 times faster. I've also added FIXMEs on a couple of behaviours that seem a little suspect, while keeping them behaving as they were - I'll look into these soon. The test changes here are mostly tedious reorganization, because the ordering of regions we output has become slightly (but not completely) more consistent from the almost completely arbitrary ordering we got before. llvm-svn: 218738
2014-10-01 11:33:52 +08:00
// CHECK-LABEL: func3:
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: Expansion,File 0, [[@LINE+3]]:14 -> [[@LINE+3]]:16 = #0
// CHECK-NEXT: File 0, [[@LINE+2]]:16 -> [[@LINE+4]]:4 = #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:1 -> [[@LINE+3]]:4 = #0
void func3() M1
int x = 0;
M11
// CHECK-NEXT: Expansion,File 1, 4:12 -> 4:14 = #0
// CHECK-NEXT: Expansion,File 2, 6:13 -> 6:16 = #0
// CHECK-NEXT: File 3, 3:12 -> 3:13 = #0
// CHECK-NEXT: File 4, 5:13 -> 5:14 = #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
InstrProf: Avoid repeated linear searches in a hot path When generating coverage regions, we were doing a linear search through the existing regions in order to try to merge related ones. Most of the time this would find what it was looking for in a small number of steps and it wasn't a big deal, but in cases with many regions and few mergeable ones this leads to an absurd compile time regression. This changes the coverage mapping logic to do a single sort and then merge as we go, which is a bit simpler and about 100 times faster. I've also added FIXMEs on a couple of behaviours that seem a little suspect, while keeping them behaving as they were - I'll look into these soon. The test changes here are mostly tedious reorganization, because the ordering of regions we output has become slightly (but not completely) more consistent from the almost completely arbitrary ordering we got before. llvm-svn: 218738
2014-10-01 11:33:52 +08:00
// CHECK-LABEL: func4:
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: Expansion,File 0, [[@LINE+3]]:14 -> [[@LINE+3]]:16 = #0
// CHECK-NEXT: File 0, [[@LINE+2]]:16 -> [[@LINE+2]]:20 = #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:17 -> [[@LINE+1]]:20 = #0
InstrProf: Avoid repeated linear searches in a hot path When generating coverage regions, we were doing a linear search through the existing regions in order to try to merge related ones. Most of the time this would find what it was looking for in a small number of steps and it wasn't a big deal, but in cases with many regions and few mergeable ones this leads to an absurd compile time regression. This changes the coverage mapping logic to do a single sort and then merge as we go, which is a bit simpler and about 100 times faster. I've also added FIXMEs on a couple of behaviours that seem a little suspect, while keeping them behaving as they were - I'll look into these soon. The test changes here are mostly tedious reorganization, because the ordering of regions we output has become slightly (but not completely) more consistent from the almost completely arbitrary ordering we got before. llvm-svn: 218738
2014-10-01 11:33:52 +08:00
void func4() M1 M11
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: Expansion,File 1, 4:12 -> 4:14 = #0
// CHECK-NEXT: Expansion,File 2, 6:13 -> 6:16 = #0
// CHECK-NEXT: File 3, 3:12 -> 3:13 = #0
// CHECK-NEXT: File 4, 5:13 -> 5:14 = #0