@@ -34,13 +34,15 @@ $(LI It can be used to track down why a particular section of code
34
34
35
35
$(LI Since execution counts are given for each line, it is possible
36
36
to use the coverage analysis to reorder the basic blocks in
37
- a function to minimize jmps in the most used path, thus
38
- optimizing it.)
39
- )
37
+ a function to minimize branches in the most used path, reducing stress
38
+ on the processor's pipeline (a run-of-the-mill X86 processor can usually handle 48 branches in its pipeline). This technique
39
+ is a special case of $(LINK2 https://en.wikipedia.org/wiki/Profile-guided_optimization, profile-guided optimization), which can
40
+ be performed automatically if either the `LLVM` or `GCC` backend is utilized.
41
+ ))
40
42
41
43
$(P Experience with code coverage analyzers show that they dramatically
42
44
reduce the number of bugs in shipping code.
43
- But it isn't a panacea, a code coverage analyzer won't help with:)
45
+ But it isn't a panacea, a code coverage analyzer won't help (unlike Valgrind or the sanitizers available in GCC and LLVM) with:)
44
46
45
47
$(OL
46
48
$(LI Identifying race conditions.)
@@ -51,18 +53,18 @@ $(LI Verifying that the program got the correct result.)
51
53
52
54
$(P Code coverage analysers are available for many popular languages,
53
55
but they are often third party products that integrate
54
- poorly with the compiler, and are often very expensive .
56
+ poorly with the compiler.
55
57
A big problem with third party products is, in order to instrument
56
- the source code, they must include what is essentially a full blown
58
+ the source code, they must include what is essentially a full- blown
57
59
compiler front end for the same language. Not only is this an expensive
58
60
proposition, it often winds up out of step with the various compiler
59
61
vendors as their implementations change and as they evolve various extensions.
60
62
($(LINK2 http://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_8.html, gcov),
61
- the Gnu coverage analyzer, is an exception as it is both free
63
+ the Gnu coverage analyzer is an exception as it is both free
62
64
and is integrated into gcc.)
63
65
)
64
66
65
- $(P The D code coverage analyser is built in as part of the D compiler.
67
+ $(P The D code coverage analyser is part of the D compiler.
66
68
Therefore, it is always in perfect synchronization with the language
67
69
implementation. It's implemented by establishing a counter for each
68
70
line in each module compiled with the $(DDSUBLINK dmd,switch-cov, $(B -cov)) switch.
@@ -78,7 +80,7 @@ $(P For example, consider the Sieve program:)
78
80
79
81
import std.stdio;
80
82
81
- bool flags [8191];
83
+ bool[8191] flags ;
82
84
83
85
int main()
84
86
{
@@ -124,7 +126,7 @@ $(CONSOLE
124
126
|
125
127
|import std.stdio;
126
128
|
127
- |bool flags [8191];
129
+ |bool[8191] flags ;
128
130
|
129
131
|int main()
130
132
|{
@@ -163,13 +165,13 @@ as the execution count.
163
165
At the end of the .lst file, the percent coverage is given.
164
166
)
165
167
166
- $(P There are 3 lines with an exection count
168
+ $(P There are 3 lines with an execution count
167
169
of 1, these were each executed once. The declaration line for $(D i, prime),
168
170
etc., has 5 because there are 5 declarations, and the initialization of
169
171
each declaration counts as one statement.)
170
172
171
173
$(P The first $(D for) loop shows 22. This is the sum of the 3 parts
172
- of the for header. If the for header is broken up into 3 lines, the
174
+ of the for- header. If the for- header is broken up into 3 lines, the
173
175
data is similarly divided:)
174
176
175
177
$(CONSOLE
@@ -263,7 +265,7 @@ sieve --DRT-covopt="merge:1 dstpath:reports"
263
265
264
266
$(H3 References)
265
267
266
- $(LINK2 https://en.wikipedia.org/wiki/Code_coverage, Wikipedia)
268
+ $(LINK2 https://en.wikipedia.org/wiki/Code_coverage, Wikipedia: "Code Coverage" )
267
269
268
270
)
269
271
0 commit comments