This is an archive of the discontinued LLVM Phabricator instance.

Tests for coverage mapping
ClosedPublic

Authored by arphaman on Aug 5 2014, 11:05 AM.

Details

Summary

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 IR.

This patch depends on the updated command line coverage tool.

Diff Detail

Repository
rL LLVM

Event Timeline

arphaman updated this revision to Diff 12204.Aug 5 2014, 11:05 AM
arphaman retitled this revision from to Tests for coverage mapping.
arphaman updated this object.
arphaman edited the test plan for this revision. (Show Details)
arphaman added reviewers: bob.wilson, bogner.
arphaman set the repository for this revision to rL LLVM.
arphaman added a subscriber: Unknown Object (MLST).
rnk added a subscriber: rnk.Aug 5 2014, 11:29 AM
rnk added inline comments.
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

I don't think we allow execution tests in Clang's internal test suite. Can this live in test-suite?

arphaman added inline comments.Aug 5 2014, 11:33 AM
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

I can take out the execution part then, so it will look something like this:

RUN: %clang %s -fprofile-instr-generate -fcoverage-mapping -O2 -o %stest
RUN: llvm-cov dump %stest| FileCheck %s

rnk added inline comments.Aug 5 2014, 12:00 PM
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

Even this test would rely on having a system linker that can link a binary for LLVM_DEFAULT_TARGET_TRIPLE, which might not be a native architecture. Can llvm-cov -dump run on an object file? Is that a useful test?

This kind of large execution test for coverage seems valuable, but I don't think we can reasonably expect it to pass in every supported configuration. It seems to me like it's a better fit for test-suite. We can definitely keep the IRGen tests, though.

test/CoverageMapping/code.h
1 ↗(On Diff #12204)

This would have to be in Inputs/

test/CoverageMapping/tu2.cpp
1 ↗(On Diff #12204)

This would have to be in Inputs/

arphaman added inline comments.Aug 5 2014, 12:20 PM
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

I see your point. In that case I can just compile and create an object file, and llvm-cov should be able to dump the info from it as long as LLVM's object file API's support the object file format. This would be a useful test indeed, as I'm looking at the mapping regions produced by clang and the execution counts don't matter.

arphaman added inline comments.Aug 5 2014, 2:02 PM
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

The object file tests will work with slight modifications to the coverage reader code.

As a result of that the tests will use:

RUN: %clang %s -c -fprofile-instr-generate -fcoverage-mapping -o %stest
RUN: llvm-cov dump %stest | FileCheck %s

arphaman added inline comments.Aug 5 2014, 2:11 PM
test/CoverageMapping/break.c
3 ↗(On Diff #12204)

Another thing that I can do is to add an option to clang to dump the coverage mapping info instead of relying on a separate tool. Something like "clang -cc1 -dump-coverage-mapping".
This might be an even better approach.

arphaman updated this revision to Diff 12213.Aug 5 2014, 4:25 PM

I've updated the patch to test using the 'dump-coverage-mapping' option instead of relying on external tools.

arphaman closed this revision.Aug 8 2014, 4:59 PM
arphaman updated this revision to Diff 12321.

Closed by commit rL215261 (authored by @arphaman).