similar to: GSoC Proposal : Path Profiling Support

Hi Vedant, I would like to clarify that the proposal does *intra-procedural* path profiling as described in [Ball96]. > > 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

Hi David, > Are the data below all collected when only one function is picked for > instrumentation? Yes, here is a list of the benchmarks and selected functions. +-----------------+----------------------------------------------------------------------------------------------+ | blks | _Z19BlkSchlsEqEuroNoDivfffffif |

Hi I am pinging to find out if there is any interest to mentor this proposal for GSoC this year? I've submitted a draft via the GSoC website. David, Vedant it would be great if I could get some advice on refining the goals and particulars of the implementation. The version we use internally is not performance oriented and will require refactoring. Here is a link to the draft document [1].

Hi Snehasish, thanks for writing up the proposal. As it stands today, path profiling still has serious scalability issue that prevents it from being usable by any optimization passes that may benefit from it. On the other hand, sampling based approach can still be promising. For instance, LBR can potentially together with static CFG constructed from the binary can be used to form path(let)

Hi David, > Hi Snehasish, thanks for writing up the proposal. > > As it stands today, path profiling still has serious scalability issue that > prevents it from being usable by any optimization passes that may benefit > from it. I agree; it would be an interesting to see how we can reduce the overheads to bring it within acceptable limits. > It will be interesting to see how

On Friday 10 July 2009 18:06, Slobodan Pejic wrote: > Hello, > > I am planning on contributing path profiling to LLVM by the end of > August. I have written a document of what the interface to the path > profiles would look like at that time. If someone has any amendments, I > can incorporate them. > > http://www.cs.ualberta.ca/~pejic/PathProfiling.html Slobodan, This

David Greene wrote: > On Friday 10 July 2009 18:06, Slobodan Pejic wrote: >> Hello, >> >> I am planning on contributing path profiling to LLVM by the end of >> August. I have written a document of what the interface to the path >> profiles would look like at that time. If someone has any amendments, I >> can incorporate them. >> >>

I want to get path profiling information with LLVM. LLVM provides methods for path profiling.I also get the llvmprof.out successfully. So I want to output the result.With llvm-prof ,I get the error:llvm-prof: Unkknown packet #5. So I have to write my own pass to output the path profiling result,the following is my kernel codes:

On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote: > The flags -fprofile-generate and -fprofile-use are currently ignored > for GCC compatibility. I would like to enable them and give them > similar semantics to GCC. These flags are baked pretty deeply into > our build environment, so supporting them at the driver level will > make our lives a lot

Hi, Regarding the mischeduler, I wonder // For loops that are acyclic path limited, aggressively schedule for // latency. This can result in very long dependence chains scheduled in // sequence, so once every cycle (when CurrMOps == 0), switch to normal // heuristics. if (Rem.IsAcyclicLatencyLimited && !Zone->getCurrMOps() && tryLatency(TryCand, Cand, *Zone))

Hi, I have a question regarding PGO. I collected profile data with the instrumentation build (-fprofile-instr-generate) and provided for PGO optimization in the second build (with -fprofile-instr-use=xxx.profdata). This works fine. Then I tried to provide the profile data to opt using the option -pgo-instr-use, but this causes an error with the message: "Not an IR level instrumentation

Alright, I'm ready to nuke it. Last chance to say stop. For context of others, this has come up repeatedly: no one we know of is using EdgeProfiling.cpp, PathProfiling.cpp, and the lib/Analysis/Profile*Pass.cpp collection of tools. They haven't been updated since 2012 when Alastair Murray looked into this stuff, and both current efforts towards PGO are essentially *totally* different

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:

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

Teresa Johnson <tejohnson at google.com> writes: > On Wed, Apr 29, 2015 at 6:27 AM, Renato Golin <renato.golin at linaro.org> wrote: >> 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

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

There have been a lot of responses. I'll try to summarize the thread and respond to some of the questions/feedback. Summary ======= 1. We should teach GlobalDCE to strip out instrumented functions which the inliner cannot delete. 2. Sean suggests adding metadata to loads/stores of counters to convey that they do not alias normal program data. I'm not familiar with AA, but

BTW, this will also remove the entire 'runtime' directory in the LLVM repository. Runtime libraries are now being developed in compiler-rt. That is where the GCDA profiling runtime already lives and any new instrumentation based profiling runtime would also likely live there. If the code in the existing runtime tree is needed to start building those, they can always be found in the VCS

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

Ok, thanks for the suggestion. I will rework the tests to do that. Teresa On Wed, Apr 29, 2015 at 9:47 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 9:36 AM Justin Bogner <mail at justinbogner.com> wrote: >> >> Teresa Johnson <tejohnson at google.com> writes: >> > On Wed, Apr 29, 2015 at 6:27 AM, Renato Golin