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

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

22 lines
628 B
C
Raw Normal View History

Reland [Coverage] Add comment to skipped regions Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757. Add comment to skipped regions so we don't track execution count for lines containing only comments. Differential Revision: https://reviews.llvm.org/D83592
2020-07-23 10:04:59 +08:00
// RUN: %strip_comments > %t.stripped.c
// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only -main-file-name macroparams2.c %t.stripped.c | 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 MACRO(REFS, CALLS) (4 * (CALLS) < (REFS))
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
struct S {
int i, j;
};
Revert "[Coverage] Enable emitting gap area between macros" This reverts commit a31c89c1b7a0a2fd3e2c0b8a587a60921abf4abd.
2020-08-26 06:04:33 +08:00
// CHECK: File 0, [[@LINE+1]]:12 -> [[@LINE+10]]:2 = #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
int main() {
struct S arr[32] = { 0 };
int n = 0;
Revert "[Coverage] Enable emitting gap area between macros" This reverts commit a31c89c1b7a0a2fd3e2c0b8a587a60921abf4abd.
2020-08-26 06:04:33 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:7 -> [[@LINE+2]]:12 = #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-NEXT: File 0, [[@LINE+1]]:34 -> [[@LINE+3]]:4 = #1
if (MACRO(arr[n].j, arr[n].i)) {
n = 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
}
return n;
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: File 1, 3:29 -> 3:51 = #0