search for: d44892

Hi, On 2018-07-19 14:57:42 +0200, Frank Tetzel via llvm-dev wrote: > > Have you seen https://reviews.llvm.org/D44892? we are using it in > > Julia to use perf on jitted code. > > No, I did not see this patch before. Thanks a lot for the pointer. > > It seems to be doing exactly what I want. Let's see if I get it working. FWIW, I just merged this. Did you have any luck getting it to work?...

Have you seen https://reviews.llvm.org/D44892? we are using it in Julia to use perf on jitted code. -Valentin On Wed, 18 Jul 2018 at 17:13 Frank Tetzel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Hello, > > > > is there any support in LLVM for the jitdump format [1] of perf? > > > > It enables p...

...9849 [.] 0x00007f9c34d51065 + 27.71% 6.09% my_binary [JIT] tid 149849 [.] 0x00007f9c34d51060 It seems that perf report is looking for a shared object in /tmp/perf-149849.map, but that file doesn't exist. Looking at examples in the original LLVM change ( https://reviews.llvm.org/D44892?), I don't see any mentions of perf.map file. Do I miss something? Are there any examples of how to use perf listener? Thanks, Eugene -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/bc8499e9/atta...

Hello, is there any support in LLVM for the jitdump format [1] of perf? It enables perf report to also "zoom in" and annotate the JIT compiled code on assembly level with runtime percentage. It helps a lot to understand which parts of the generated code is the bottleneck. I recently did a proof-of-concept for the JIT assembler asmjit [2]. It just dumps the generated code in the right

...m a C programmer these days, and a lot of my C++ > knowledge has been replaced by other things... It's still not super > clean, but I think in a good enough state for you to estimate > complexity. After considerable further cleanup I've submitted this as: https://reviews.llvm.org/D44892 I'd greatly appreciate reviews! > What do you think? I've below included some example output to show > what's going on. > > A random example (source c file also attached): > # generate some IR, with debug info > clang -ggdb -S -c -emit-llvm expensive_loop.c -o tmp/e...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that