search for: fcoverage

...Here is simple snippets test1.c: NOT OK ================== #include <stdio.h> static int foo() { return 42; } int main() { return 0; } ================== cp src/test1.c src/test.c; rm -fr default.profraw test.profdata ; clang -c -o obj/test.o src/test.c -I -g -O0 -fprofile-instr-generate -fcoverage-mapping; clang -o bin/test obj/test.o -I -g -O0 -fprofile-instr-generate -fcoverage-mapping; ./bin/test ; llvm-profdata merge -o test.profdata default.profraw; llvm-cov show ./bin/test -instr-profile=test.profdata error: Failed to load coverage: Malformed profile data test2.c: OK ==============...

...tation. So, I'd like to see the driver do this (on all platforms): > > > > * -fprofile-instr-generate: IR instrumentation > > * -fprofile-instr-generate=IR: IR instrumentation > > * -fprofile-instr-generate=FE: FE instrumentation > > * -fprofile-instr-generate -fcoverage-mapping: FE + coverage > instrumentation > > I feel like this would be simpler: > * -fcoverage-mapping: -fprofile-instr-generate=FE + coverage > instrumentation > > Maybe there's a downside I'm not seeing though? > I proposed the same change in proposal B in the...

...lies* FE-based instrumentation. So, I'd like to see the driver do this (on all platforms): > > * -fprofile-instr-generate: IR instrumentation > * -fprofile-instr-generate=IR: IR instrumentation > * -fprofile-instr-generate=FE: FE instrumentation > * -fprofile-instr-generate -fcoverage-mapping: FE + coverage instrumentation I feel like this would be simpler: * -fcoverage-mapping: -fprofile-instr-generate=FE + coverage instrumentation Maybe there's a downside I'm not seeing though? Also, I don't like "FE". Maybe "source"? And instead of &quot...

Thank you for doing this. The size issue is actually a big concern for me. So this is step in the right direction. Two other points to consider, that would help us: 1) When using -fcoverage-mapping, some of the information is emitted in the text section. This is creating linking issues with very large files. It does not seem any of this information should necessarily be in the text section. 2) Could the information emitted for -fcoverage-mapping be placed into their own sect...

...irst\n"); return 0; } ////////// end ////////// second.cc #include "shared.h" int main() { Print2("Second\n"); return 0; } ////////// end I use the following commands to build 'first' and 'second' binaries: clang++ -O0 -c -fprofile-instr-generate -fcoverage-mapping shared.cc -o ./out/shared.o clang++ -O0 -fprofile-instr-generate -fcoverage-mapping ./out/shared.o first.cc -o ./out/first clang++ -O0 -fprofile-instr-generate -fcoverage-mapping ./out/shared.o second.cc -o ./out/second I then use the following to run the binaries: LLVM_PROFILE_FILE=...

...lly okay with. The reduced overhead of >> IRPGO is really important on PS4 (i.e. the difference between the >> instrumented game being playable or not). I really don't want to have to >> test the triple to determine the meaning of `-fprofile-instr-generate` >> (without `-fcoverage-mapping`). >> >> >> And I agree that IRPGO is better for your users, but the best workflow >> for your users is not necessarily the best workflow for every clang user. I >> totally agree with you that testing the triple to decide the meaning of the >> option is w...

...S4 is not something that I'm really okay with. The reduced overhead of IRPGO is really important on PS4 (i.e. the difference between the instrumented game being playable or not). I really don't want to have to test the triple to determine the meaning of `-fprofile-instr-generate` (without `-fcoverage-mapping`). And I agree that IRPGO is better for your users, but the best workflow for your users is not necessarily the best workflow for every clang user. I totally agree with you that testing the triple to decide the meaning of the option is wrong to do upstream. The best default is not a platfo...

...ead of >>>> IRPGO is really important on PS4 (i.e. the difference between the >>>> instrumented game being playable or not). I really don't want to have to >>>> test the triple to determine the meaning of `-fprofile-instr-generate` >>>> (without `-fcoverage-mapping`). >>>> >>>> >>>> And I agree that IRPGO is better for your users, but the best workflow >>>> for your users is not necessarily the best workflow for every clang user. I >>>> totally agree with you that testing the triple to decide...

...in behavior quiet extensively, and I after having changed my mind a couple times, I would argue in favor of keeping the current behavior for the existing flags. I think adding a new switch for IRPGO is a better option. The argument that weighted most on my opinion is the proposed interaction with -fcoverage-mapping, and it is not at all platform specific. With the proposed new behavior, turning coverage on and off in your build system will generate a binary with different performance characteristics and this feels really wrong. > > Bob already mentioned in the other thread that `-fprofile-instr...

...he reduced overhead of >>> IRPGO is really important on PS4 (i.e. the difference between the >>> instrumented game being playable or not). I really don't want to have to >>> test the triple to determine the meaning of `-fprofile-instr-generate` >>> (without `-fcoverage-mapping`). >>> >>> >>> And I agree that IRPGO is better for your users, but the best workflow >>> for your users is not necessarily the best workflow for every clang user. I >>> totally agree with you that testing the triple to decide the meaning of the...

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(optimi...

...//////// second.cc > #include "shared.h" > > int main() { > Print2("Second\n"); > return 0; > } > ////////// end > > I use the following commands to build 'first' and 'second' binaries: > clang++ -O0 -c -fprofile-instr-generate -fcoverage-mapping shared.cc > -o ./out/shared.o > clang++ -O0 -fprofile-instr-generate -fcoverage-mapping > ./out/shared.o first.cc -o ./out/first > clang++ -O0 -fprofile-instr-generate -fcoverage-mapping > ./out/shared.o second.cc -o ./out/second > > I then use the following to run t...

Umesh Kalappa <umesh.kalappa0 at 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...

...the profiling data? > > > > At compile time, it is the macro: INST_PROF_RAW_VERSION. At runtime, it is > the second field of the raw profile header. I'm not able to use INST_PROF_RAW_VERSION at compile time. Are you sure this is exported? If I do: cc -fprofile-instr-generate -fcoverage-mapping -dM -E - < /dev/null I don't see INST_PROF_RAW_VERSION neither any similar defines. > I'm mostly worried that at some point llvm will bump the version > > and change the layout, and then I will have to update my runtime > > accordingly, but without llvm...

...e-instr-generate *implies* FE-based instrumentation. So, I'd like to see the driver do this (on all platforms): * -fprofile-instr-generate: IR instrumentation * -fprofile-instr-generate=IR: IR instrumentation * -fprofile-instr-generate=FE: FE instrumentation * -fprofile-instr-generate -fcoverage-mapping: FE + coverage instrumentation It's a bit ugly because the meaning of -fprofile-instr-generate becomes context-sensitive. But, (1) it doesn't break existing common workflows and (2) it makes it easier to ship IRPGO. The big caveat here is that we'll need to wait a bit and see i...

...in behavior quiet extensively, and I after having changed my mind a couple times, I would argue in favor of keeping the current behavior for the existing flags. I think adding a new switch for IRPGO is a better option. The argument that weighted most on my opinion is the proposed interaction with -fcoverage-mapping, and it is not at all platform specific. With the proposed new behavior, turning coverage on and off in your build system will generate a binary with different performance characteristics and this feels really wrong. I would actually make the IRPGO mode completely incompatible with the -fco...

...only the library is instrumented). It seems like the inline member functions defined in headers are not instrumented in this case because the clients are not instrumented. The library itself does not have a copy of the inline methods either. In below example, > clang++ -fprofile-instr-generate -fcoverage-mapping -c foobar.cpp -o foobar.o > clang++ main.cpp foobar.o -o foobar > LLVM_PROFILE_FILE="foo.profraw" ./foobar > llvm-profdata merge -sparse foo.profraw -o foo.profdata > llvm-cov show ./foobar -instr-profile=foo.profdata """ 1| |#include "fo...

...-based > instrumentation. So, I'd like to see the driver do this (on all platforms): > > * -fprofile-instr-generate: IR instrumentation > * -fprofile-instr-generate=IR: IR instrumentation > * -fprofile-instr-generate=FE: FE instrumentation > * -fprofile-instr-generate -fcoverage-mapping: FE + coverage > instrumentation > > It's a bit ugly because the meaning of -fprofile-instr-generate becomes > context-sensitive. But, (1) it doesn't break existing common workflows and > (2) it makes it easier to ship IRPGO. The big caveat here is that we'll >...

It sounds to me we are likely to converge on the following: 1) Making IR/llvm based PGO the default; 2) Enhance -fcoverage-mapping such that it automatically turns on FE based instrumentation 3) if -fcoverage-mapping is used together with -fprofile-instr-generate, -fcoverage-mapping serves as a switch to turn on FE based instrumetnation All the above are transparent to users. The following are for advanced usage: 4)...

...*...:(__llvm_prf_data[__profv__**ZNK4llvm3cfg6UpdateIPNS_**10BasicBlockEE4dumpEv]+0x18): **undefined reference to `llvm::cfg::Update<llvm::**BasicBlock*>::dump() const'* I see this issue only when I compile the app with the following compiler options: *-g -O2 -fprofile-instr-generate -fcoverage-mapping* I don't use any special flags when I build LLVM. I used g++-7 (or clang++-9) to compile LLVM static libs. The issue does not appear with LLVM 6.0.0. I included all LLVM libraries in the same order whatever *llvm-config --libs *outputs. What lib am I missing? Or is this a known issue...