search for: llvm_profile_file

...enerate -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='./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/fi...

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

...or make and things will just work, but with the current default profile dumping mode, it can fail in many different ways: >> 1) Just run ninja/make -- all clang processes will dump profile into the same file concurrently -- the result is a corrupted profile -- FAIL >> 2) run ninja with LLVM_PROFILE_FILE=....%p >> 2.1) failure mode #1 --> really slow build due to large IO; or running out of diskspace >> 2.2) failure mode #2 --> pid recyling leading to profile file name conflict -- profile overwriting happens and we loss data >> >> Suppose 2) above finally succee...

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

...refix> does not exist, it is created by the runtime. 2. -fprofile-use=path-prefix would cause the compiler to read from <path-prefix>/default.profile. 3. I could also add support for -fprofile-dir, but we don't really use it internally. As with -fprofile-instr-generate, LLVM_PROFILE_FILE would override the path prefix and name of the profile file. Does this sound reasonable? Thanks. Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/4e979033/attachment.html>

...un ninja or make and things will just work, but with the current default profile dumping mode, it can fail in many different ways: > 1) Just run ninja/make -- all clang processes will dump profile into the same file concurrently -- the result is a corrupted profile -- FAIL > 2) run ninja with LLVM_PROFILE_FILE=....%p > 2.1) failure mode #1 --> really slow build due to large IO; or running out of diskspace > 2.2) failure mode #2 --> pid recyling leading to profile file name conflict -- profile overwriting happens and we loss data > > Suppose 2) above finally succeeds, the user wil...

...the Clang guide clarifying that 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.profd...

...implement the core merging logic and add to buffer API a primitive for merging two buffers b) implement the file system glue to extend this to the filesystem API's (write_file etc.) c) implement a profile filename format string which generates a random number mod a specified amount (strawman: `LLVM_PROFILE_FILE=default.profraw.%7u` which generates a _u_nique number mod 7. Of course, in general it is `%<N>u`) b) depends on a), but c) can be done in parallel with both. Does this seem feasible? -- Sean Silva On Tue, Mar 1, 2016 at 2:55 PM, Xinliang David Li <davidxl at google.com> wrote: &g...

...ompiler, run ninja or make and things will just work, but with the current default profile dumping mode, it can fail in many different ways: 1) Just run ninja/make -- all clang processes will dump profile into the same file concurrently -- the result is a corrupted profile -- FAIL 2) run ninja with LLVM_PROFILE_FILE=....%p 2.1) failure mode #1 --> really slow build due to large IO; or running out of diskspace 2.2) failure mode #2 --> pid recyling leading to profile file name conflict -- profile overwriting happens and we loss data Suppose 2) above finally succeeds, the user will have to merge thou...

...le case though, I think it's too magical when pointing at a directory. > • I could also add support for -fprofile-dir, but we don't > really use it internally. I don't think it's necessary unless someone actually wants to use it. > As with -fprofile-instr-generate, LLVM_PROFILE_FILE would override > the path prefix and name of the profile file. > > Does this sound reasonable? > > > Thanks. Diego.

...t 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 th...

On Fri, May 22, 2015 at 11:16 AM, Dario Domizioli <dario.domizioli at gmail.com> wrote: > Hi all, > > I am a bit confused about the documentation of the format of the profile > data file. > > The Clang user guide here describes it as an ASCII text file: > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > Whereas the posts above and the

On Sat, Feb 27, 2016 at 6:50 PM, Sean Silva <chisophugis at gmail.com> wrote: > I have thought about this issue too, in the context of games. We may want > to turn profiling only for certain frames (essentially, this is many small > profile runs). > > However, I have not seen it demonstrated that this kind of refined data > collection will actually improve PGO results in

Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the main missing features in Clang/LLVM profile runtime is the lack of > support for online/in-process profile merging support. Profile data collected > for different workloads for the same executable binary need to be collected > and merged later by the offline post-processing tool.  This limitation

Hi all, I am a bit confused about the documentation of the format of the profile data file. The Clang user guide here describes it as an ASCII text file: http://clang.llvm.org/docs/UsersManual.html#sample-profile-format Whereas the posts above and the referenced link describe it as a stream of bytes containing LEB128s: http://www.llvm.org/docs/CoverageMappingFormat.html >From experimenting

I have thought about this issue too, in the context of games. We may want to turn profiling only for certain frames (essentially, this is many small profile runs). However, I have not seen it demonstrated that this kind of refined data collection will actually improve PGO results in practice. The evidence I do have though is that IIRC Apple have found that almost all of the benefits of PGO for

One of the main missing features in Clang/LLVM profile runtime is the lack of support for online/in-process profile merging support. Profile data collected for different workloads for the same executable binary need to be collected and merged later by the offline post-processing tool. This limitation makes it hard to handle cases where the instrumented binary needs to be run with large number of