search for: profraw

Hi all, I'm now working on llvm-cov for a new target and have a problem here. Because of some reasons, users do not stub in the main function and after running elf file, they cannot get a default profraw. Now they want to construct a default profraw manually but don't know how data is laid out in `default profraw` file. We found a struct ProfDataIOVec in InstrProfilingWriter.c in compiler-rt and followed this layout. ``` ProfDataIOVec IOVec[] = { {&Header, sizeof(__llvm_profile_h...

...llvm revision: r228136 clang Last Changed Rev: 228121 build: Debug+Asserts OS: ubuntu 14.04 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=tes...

...Because this is not a hosted environment, we have to off-chip the profiling data ourselves, and although the data looks okay, 'llvm-profdata' reports the following error: llvm-profdata show -all-functions -counts -detailed-summary -text -static-func-full-module-prefix ~/Downloads/default.profraw error: ~/Downloads/default.profraw: Failed to uncompress data (zlib) But even for a hosted system, it is not clear to me where 'zlib' gets involved in compressing the data. The start of our data looks like: hexdump -C default.profraw 00000000 81 52 66 6f 72 70 6c ff 04 00 00 00 00 0...

...off-chip the >> profiling data ourselves, and although the data looks okay, ‘llvm-profdata’ >> reports the following error: >> >> >> >> *llvm-profdata show -all-functions -counts -detailed-summary -text >> -static-func-full-module-prefix ~/Downloads/default.profraw* >> >> error: ~/Downloads/default.profraw: Failed to uncompress data (zlib) >> >> >> >> But even for a hosted system, it is not clear to me where ‘zlib’ gets >> involved in compressing the data. The start of our data looks like: >> >> >>...

...t; -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Justin Bogner via llvm-dev > Sent: 18 July 2017 19:37 > To: Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] PGO, zlib and 'default.profraw' > > Can we improve the error message here? We should be able to check > zlib::isAvailable and give an error like "profile uses zlib compression but > the profile reader was built without zlib support" or so in this case. > > Xinliang David Li via llvm-dev <llvm-d...

...Or “SORT” clauses? Thanks, MartinO From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] Sent: 19 July 2017 15:56 To: Xinliang David Li <xinliangli at gmail.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] PGO, zlib and 'default.profraw' Thanks. Yes, I build ‘clang’ and all the other tools and utilities together, so I am surprised that ‘clang’ would have ‘zlib’ enabled but not ‘llvm-profdata’. I will get back to this when I return on Monday, and I have a suspicion I may be doing something else wrong that I will formulate...

...c -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='./out/first.profraw' ./out/first LLVM_PROFILE_FILE='./out/second.profraw' ./out/second I then use the following commands to show the report: llvm-profdata merge -sparse ./out/first.profraw ./out/second.profraw -o ./out/all.profdata llvm-cov show ./out/second -object ./out/first -instr-profile ./out/...

...ently I'm trying to use LLVM PGO and autoFDO. However I have some problems in the process. LLVM source code is updated on April 9th. Operating system is SUSE x86_64 1. Problems in instrumentation based PGO: clang -O2 -fprofile-instr-generate test.c -o a.out ./a.out (then default.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out error: pgo data file has malformed function entry I found that the run-time function "writeFile" in InstrProfilingFile.cpp didn't write '\n'. But when parsing the profile data, in CodeGenPGO....

...+ -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='./out/first.profraw' ./out/first > LLVM_PROFILE_FILE='./out/second.profraw' ./out/second > > I then use the following commands to show the report: > llvm-profdata merge -sparse ./out/first.profraw ./out/second.profraw > -o ./out/all.profdata > llvm-cov show ./out/second -object ./out/...

...n 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 "foobar.h" 2| | 3| | 4| |void FooBar::foo(void) 5| 1|{ 6| 1| prin...

...PORT_COMPILE_COMMANDS=ON \ -DCMAKE_CXX_COMPILER=/path/to/instrumented_build/bin/clang++ \ -DCMAKE_C_COMPILER=/path/to/instrumented_build/bin/clang \ -DLLVM_USE_LINKER=/path/to/release_build/bin/ld.lld \ -DLLVM_CCACHE_BUILD=ON * Tried to use /path/to/instrumented_build/llvm-profdata on the profraw files found in /path/to/instrumented_build/profiles/. I got the following error message: error: profiles/default_15822678447050577402_0.profraw: Profile uses zlib compression but the profile reader was built without zlib support Even when I explicitly specified zlib to be enabled, and double che...

...on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in the profdata file for the 2nd PGO compile pass This all works well with LLVM 3.7. While testing this with LLVM trunk, I run into a version compatibility problem between different versions of LLVM: I made a local copy of the compile...

...eProfiler and __llvm_profile_initialize_file from the startup before main and __llvm_profile_write_file during the exit after main. 3. Made changes in the compiler-rt library to adapt the profile sources for a bare metal target. When i run the elf file of a simple return 0 main i do get a default.profraw file and after processing the raw data using llvm-profdata and llvm-cov all i get is error: a.out: Failed to load coverage: No coverage data found I could see the following : $ llvm-profdata.exe show -detailed-summary default.profraw Total functions: 1 Maximum function count: 1 Maximum internal...

...PILER=/path/to/instrumented_build/bin/clang++ \ >> -DCMAKE_C_COMPILER=/path/to/instrumented_build/bin/clang \ >> -DLLVM_USE_LINKER=/path/to/release_build/bin/ld.lld \ >> -DLLVM_CCACHE_BUILD=ON >> >> * Tried to use /path/to/instrumented_build/llvm-profdata on the profraw >> files found in /path/to/instrumented_build/profiles/. >> >> I got the following error message: >> error: profiles/default_15822678447050577402_0.profraw: Profile uses zlib >> compression but the profile reader was built without zlib support >> >> Even w...

...ke `llvm.*` which tools are not allowed to drop (or that have special handling inside tools). Assuming that we have a semantics that guarantees that some labels/"metadata" are kept (and that the compiler can communicate certain predefined labels to the runtime which propagate back to the profraw and then to the profdata), what do you think about using a generic format like this for things like versions and profile source, rather than attempting to fit everything in a small version field or having to come up with some convention for a variable being defined or not (as in http://reviews.llvm...

...p -o main.regular > > > hand: main2.cpp > > clang++ -O2 main2.cpp -o main.regular2 > > > instr: main.cpp > > clang++ -O2 -fprofile-instr-generate main.cpp -o main.instr > > > profile: main.instr > > ./main.instr > > > merge: default.profraw > > xcrun llvm-profdata merge -output default.profdata default.profraw > > > optimize: default.profdata > > clang++ -O2 -fprofile-instr-use=default.profdata main.cpp -o > main.optimized > > > clean: > > $(RM) default.* main.instr main.optimized mai...

...it is different from the coverage format. So, my further question is... Am I right in understanding that both formats can be used for PGO purposes then? I have tried the following, as in the Clang user guide: $ clang++ -O2 -fprofile-instr-generate code.cc -o code $ LLVM_PROFILE_FILE="code-%p.profraw" ./code $ llvm-profdata merge -output=code.profdata code-*.profraw $ clang++ -O2 -fprofile-instr-use=code.profdata code.cc -o code This produces a PGOptimized executable which performs differently (in fact, better!) than a normal O2 build, so I think the "code.profdata" file produce...

...ritical tasks are done and transfer them to outside of the system. Then dump these sections in a char * array in a c file and attribute them to be in the associated section. Then compile that file with –u__llvm_profile_runtime to create an executable that calls __llvm_profile_write_file to dump my profraw data. Sofar, I’m able to do the mechanics but seems like something is going wrong because because fprofile-instr-use does not find profile data for the source files. Any suggestion? Thanks A From: <vsk at apple.com> on behalf of Vedant Kumar <vsk at apple.com> Date: Tuesday, Decembe...

...and attribute them > to be in the associated section. > > > I'm not sure I follow -- why is a C file needed? > > Once you have the buffer from step 3 on the host machine, you've got a > well-formed raw profile. You should be able to fwrite() it to e.g > 'default.profraw' and test that it's a valid profile with llvm-profdata. > > > Then compile that file with –u__llvm_profile_runtime to create an > executable that calls __llvm_profile_write_file to dump my profraw data. > > Sofar, I’m able to do the mechanics but seems like something is g...

...e arguments, system info (uname) *III. Custom Content* The key-value store itself could be exposed to developers via the llvm-profdata tool. This would allow for users to associate arbitrary custom data with a profile, as well as inspect it: $ llvm-profdata merge -metadata=customkey,value1 foo.profraw -o foo.profdata $ llvm-profdata show -metadata foo.profdata customkey: "value1" Total functions: 4 Maximum function count: 866988873 Maximum internal block count: 267914296 Developers could add as much custom context as they find valuable: $ llvm-profdata merge -metadata=&qu...