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
This makes it possible to view sub-line region counts for the l.h.s of
&& and || expressions in coverage reports.
It also fixes PR33465, which shows an example of incorrect coverage
output for an assignment statement containing '||'.
llvm-svn: 315979
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
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
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
Vedant Kumar