Hi Justin ,
Thank you for the confirmation and we would like to know that ,going
forward the clang has the support the gcc gcov format or use the
-fprofile-instr-generate -fcoverage-mapping and get ride of gcov
format .
We are planing to customize the clang code coverage for embedded world
,before we start tweaking the gcov / -fprofile-instr-generate
code-base ,we would like to take feedback from the group .
Did -fprofile-instr-generate -fcoverage-mapping better than(optimized
instrumented) gcov ? ,if so any benchmark reference will be
appreciated.
Thank you and awaiting for your suggestions.
~Umesh
Umesh Kalappa <umesh.kalappa0@gmail.com> writes:
Hi Justin ,
Thank you for the confirmation and we would like to know that ,going
forward the clang has the support the gcc gcov format or use the
-fprofile-instr-generate -fcoverage-mapping and get ride of gcov
format .
Going forward, the -fprofile-instr-generate -fcoverage-mapping (which
I'll refer to as instrprof) work will continue to be improved and built
upon. The gcov support in llvm isn't going away, but it isn't likely to
be improved or changed much at this point.
We are planing to customize the clang code coverage for embedded world
,before we start tweaking the gcov / -fprofile-instr-generate
code-base ,we would like to take feedback from the group .
Did -fprofile-instr-generate -fcoverage-mapping better than(optimized
instrumented) gcov ? ,if so any benchmark reference will be
appreciated.
I'm not sure what you mean by better. The instrprof approach is more
accurate and has significantly lower runtime overhead than the gcov
support in llvm. It is also quite a bit simpler and more flexible in
terms of data collection. It does currently have a pretty high overhead
in terms of binary size, especially for coverage.
Thank you Justin for clarification ,was meant better here , that
instrprof is less overahed w.r.t to binary size compare to gcc .
Thank you again.
~Umesh