search for: instrprof

A few weeks ago, I started seeing 6 tests start failing in the Profile test suite of the ARM Linux build. Anyone else seeing this? They all fail with similar output: Command Output (stderr): -- compiler-rt/test/profile/instrprof-write-file.c:13:12: error: expected string not found in input // CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !prof !1 ^ <stdin>:6:17: note: scanning from here define i32 @main(i32 %argc, i8** %argv) #0 { ^ <stdin>:17:2: note: possible intended match h...

Hi all, I am working 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 fo...

...profile <path-prefix>/default.profraw. If > <path-prefix> does not exist, it is created by the runtime. > • -fprofile-use=path-prefix would cause the compiler to read > from <path-prefix>/default.profile. The path-prefix versions are a bit of an odd fit for the instrprof stuff - I'd prefer if they dealt with the path to the file. I can see how that might be difficult to do and still be compatible though. Maybe we could make the -fprofile-use= version accept a file or directory, and if a directory is specified then look for the default? The other thing that wo...

...ilures. Maybe making the names >> unique would fix the issues, would that be an easy change? > > After thinking about it I believe this is what is most likely > happening, and that these two new tests I added will need to be > reverted: > > compiler-rt/trunk/test/profile/instrprof-override-filename-then-reset-default.c > compiler-rt/trunk/test/profile/instrprof-set-filename-then-reset-default.c > > since they aren't writing to unique output names. These are 2 of the 4 > tests added in r236056 (the other two are fine). > > They can't be changed t...

...R level. However, if I try to make -pgo-instr-gen for the opt command, the resulting bitcode seems to cause a problem as follows (my environment is 3.9.0, mid Feb trunk). $ clang -c -o main.bc -O2 -m64 -emit-llvm main.c $ opt -pgo-instr-gen main.bc -o main_inst.bc $ llc main_inst.bc -o main_inst.s instrprof failed to lower an increment UNREACHABLE executed at /home/suganuma/tools/llvm_new/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5245! #0 0x00000000815ecc7a llvm::sys::PrintStackTrace (llvm::raw_ostream&) /home/suganuma/tools/llvm_new/llvm/lib/Support/Unix/Signals.inc:322:0 #1 0x0000000...

...ues, would that be an easy change? >> > >> > After thinking about it I believe this is what is most likely >> > happening, and that these two new tests I added will need to be >> > reverted: >> > >> > >> > compiler-rt/trunk/test/profile/instrprof-override-filename-then-reset-default.c >> > >> > compiler-rt/trunk/test/profile/instrprof-set-filename-then-reset-default.c >> > >> > since they aren't writing to unique output names. These are 2 of the 4 >> > tests added in r236056 (the other two ar...

Hi Gabor, I noticed that one particular test fails intermittently on the AArch64 bot: http://lab.llvm.org:8011/builders/clang-native-aarch64-full FAIL: Profile:: instrprof-set-filename-then-reset-default.c Some times on stage1, others on stage2, others no fail at all. All the commits during these builds are not related to profiling or AArch64, so I believe this has something to do with the setup. Maybe try to reproduce it locally? It could be something to do with...

...ate site for PC, they are all marked as aliases in one pass. 3. >> Erase all updates to redundant profile counters. > > When you are saying "erase", you need to actually replace the multiple counter increment with *a new* counter, right? I.e. when replacing: > > instrprof_increment(profc_f2); > instrprof_increment(profc_f1); > > you need to emit: > > instrprof_increment(profc_f2f1_fused); No. The pass only erases updates to counters which it can prove are truly redundant. There is no need to create a new (or fused) counter because profc_f1...

On 29 April 2015 at 14:16, Teresa Johnson <tejohnson at google.com> wrote: > Two of the compiler-rt/profile tests I added are checking for similar > behavior with resetting the filename to the default. I wonder if they > are running in parallel and clobbering each other since the profile > output names are not unique after the reset. Hi Teresa, This would explain the

...san-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r Profile :: instrprof-error.c Expected Passes : 31128 Expected Failures : 172 Unsupported Tests : 615 Unexpected Failures: 7 On Ubuntu 15.10 x86_64: Failing Tests (2): MemorySanitizer :: Linux/forkpty.cc MemorySanitizer :: Linux/tcgetattr.cc Expected Passes : 31860 Expected Failu...

...e 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-in...

...thinking about it I believe this is what is most likely >> >> > happening, and that these two new tests I added will need to be >> >> > reverted: >> >> > >> >> > >> >> > >> >> > compiler-rt/trunk/test/profile/instrprof-override-filename-then-reset-default.c >> >> > >> >> > >> >> > compiler-rt/trunk/test/profile/instrprof-set-filename-then-reset-default.c >> >> > >> >> > since they aren't writing to unique output names. These are 2 of t...

This proposal adds support for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at runtime. Path profiles enable precise enumeration of the sequence of basic blocks executed in order for a particular path. Using path

...ced control flow allows aggressive dead-store-elimination, dead-code-elimination and constant propagation. > > Over the last year, I have built a toolchain which uses path profiling as its basis. > Do you have any numbers about the size of path profiles, compared to the > size of raw instrprof-based profiles? No. We use a plain text representation internally which can be further optimized. > In general I'm curious about how we can support users of instrprof-style > profiles with path profiles. Do you have plans to support code coverage > using path profiles? Perfect in...

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

...t; happening, and that these two new tests I added will need to be >> >> >> > reverted: >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > compiler-rt/trunk/test/profile/instrprof-override-filename-then-reset-default.c >> >> >> > >> >> >> > >> >> >> > >> >> >> > compiler-rt/trunk/test/profile/instrprof-set-filename-then-reset-default.c >> >> >> > >> >> >&gt...

...ases in one pass. > > > 3. > > >> Erase all updates to redundant profile counters. > > > > When you are saying "erase", you need to actually replace the multiple counter increment with *a new* counter, right? I.e. when replacing: > > > > instrprof_increment(profc_f2); > > instrprof_increment(profc_f1); > > > > you need to emit: > > > > instrprof_increment(profc_f2f1_fused); > > > No. The pass only erases updates to counters which it can prove are > truly redundant. There is no need to creat...

...gt; >> Erase all updates to redundant profile counters. >> > > >> > > When you are saying "erase", you need to actually replace the >> multiple counter increment with *a new* counter, right? I.e. when replacing: >> > > >> > > instrprof_increment(profc_f2); >> > > instrprof_increment(profc_f1); >> > > >> > > you need to emit: >> > > >> > > instrprof_increment(profc_f2f1_fused); >> > >> > >> > No. The pass only erases updates to counters...

...we update the internal path >> profile data structures if we allow this at all. >> >> > > + Verify with PGOEdge info ? >> >> > Ditto. >> >> Verification with PGOEdge info implies that the edge frequencies derived >> from path profiles and via instrprof should be equal. >> >> > > + Handle setjmp, longjmp, early program termination, noreturn calls >> >> > How do you handle indirect calls? >> >> No special handling of indirect calls as path profiles are >> intra-procedural and control returns to sam...

...g well. I have a couple of points on a high level, and I'll also send some review for the patches you've sent out. - The raw profile format does not need to be backwards compatible, that's only important for the indexed one. Instead of adding RawInstrValueProfReader, just change RawInstrProfReader and reject the data if the version is 1. Similarly, don't change the raw profile magic - just bump the version to 2. - We don't need to store the value profiling kind in the data at all. The frontend knows which invocations of the intrinsic are for each kind implicitly, much...