Update for Code Coverage, Fixing Double Counts on Functions Compiled in Different Binaries and Merging of Conditional Compilation

[awearden]

The following PR is addressing these two issues:
#148279
#148673

The current state of code coverage in llvm had two bugs that occurred when merging .profraw files. Issue 148279 occurred because of the way that llvm-profdata would map functions to their respective counter values. These mappings work by using the function name and the function control flow hash to map to their counters. So, if two functions with the same name and the same control flow appear in the .profraw files, their counters will be merged. My changes address this issue by using the object file along with the function name and the function control flow hash to map to the counters. This way, binaries compiled with the same function in different binaries can be differentiated. You can see the effect of this by using the --object-aware-hashing flag implemented in llvm-profdata, and the --merge-binary-coverage flag in llvm-cov.

Example workflow:

clang -fprofile-instr-generate -fcoverage-mapping -o x86_exec_1 myprogram.c fb.c -g
./x86_exec_1
cp default.profraw x86_exec_1.profraw

clang -o x86_exec_2 mypg.c fb.c -stdlib=libc++ -fprofile-instr-generate -fcoverage-mapping
./x86_exec_2
cp default.profraw x86_exec_2.profraw

llvm-profdata merge -o all.profdata --object-aware-hashing=x86_exec_2 x86_exec_2.profraw --object-aware-hashing=x86_exec_1 x86_exec_1.profraw

llvm-cov show --object=x86_exec_1 --object=x86_exec_2 --merge-binary-coverage --instr-profile=all.profdata

the llvm-lit test case "merge-same-func-diff-bin.c" located where the llvm-cov tests exist, tests if the double counts on main appear on the example shown in issue 148279.

This same workflow also addresses the conditional compilation problems in issue 148673. The reason this issue occurred was because of the way llvm-profdata created the hash values that mapped to the counters (as explained above) and because of the duplication checks in llvm-cov. If llvm-cov sees that a particular function name has already been processed, it will skip any other mentions of that particular function. So with my changes, if a function has been processed, it will merge the execution counts and any new regions that appear into the list of Regions that is held by the first instance of the function processed. Later this combined list of Regions is then processed so that the right counts show up on any Regions that were incorrectly labeled as a "Skipped Region" during the conditional compilation. The llvm-lit test case "merge-binary-coverage.c" will test for the right counts in a conditional compilation.

Lastly, these updates also add the --show-arch-executables flag in llvm-cov, which will allow the user to see the merged function coverage, along with the specific coverage from each executable. These sub-views will list the particular object file the coverage is refering too along with the architecture of the object file. The llvm-lit test case "merge-show-arch-exec.c" does a simple test of this feature.

Example of using --show-arch-executables:

clang -fprofile-instr-generate -fcoverage-mapping -o x86_exec_1 myprogram.c fb.c -g
./x86_exec_1
cp default.profraw x86_exec_1.profraw

clang -o x86_exec_2 mypg.c fb.c -stdlib=libc++ -fprofile-instr-generate -fcoverage-mapping
./x86_exec_2
cp default.profraw x86_exec_2.profraw

llvm-profdata merge -o all.profdata --object-aware-hashing=x86_exec_2 x86_exec_2.profraw --object-aware-hashing=x86_exec_1 x86_exec_1.profraw

llvm-cov show --object=x86_exec_1 --object=x86_exec_2 --merge-binary-coverage --show-arch-executables --instr-profile=all.profdata

@quic-akaryaki
@quic-areg
@quic-seaswara
@evodius96
@chapuni

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.