similar to: [LLVMdev] JITEventListener for eventual profiling and maybe gdb support

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] JITEventListener for eventual profiling and maybe gdb support"

2009 Jun 24
0
[LLVMdev] JITEventListener for eventual profiling and maybe gdb support
Ack, sorry. I should have sent this to llvm-commits instead. :-P Followups there please. On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey Yasskin<jyasskin at google.com> wrote: > I intend to use this to support oprofile's ability to symbolize JITted > code through the interface described at > http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I > believe the interface
2009 Jun 24
3
[LLVMdev] [llvm-commits] JITEventListener for eventual profiling and maybe gdb support
Hi Jeffrey, This looks very good. Thanks. Some comments: +/// JitSymbolEntry - Each function that is JIT compiled results in one of these +/// being added to an array of symbols. This indicates the name of the function +/// as well as the address range it occupies. This allows the client to map +/// from a PC value to the name of the function. +struct JitSymbolEntry { A nitpick. Please
2009 Jun 25
0
[LLVMdev] [llvm-commits] JITEventListener for eventual profiling and maybe gdb support
On Wed, Jun 24, 2009 at 2:43 PM, Evan Cheng<evan.cheng at apple.com> wrote: > Hi Jeffrey, > > This looks very good. Thanks. Some comments: > > +/// JitSymbolEntry - Each function that is JIT compiled results in > one of these > +/// being added to an array of symbols.  This indicates the name of > the function > +/// as well as the address range it occupies.  This
2012 Nov 26
0
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
No. It adds a new event, 'NotifyObjectEmitted'. The Intel JIT listener that I mentioned then uses the emitted object to find the functions (which are all emitted together). Because of the way that MCJIT is implemented, it isn't really feasible to reconstruct things like the EmittedFunctionDetails in the NotifyFunctionEmitted event. -Andy -----Original Message----- From: Manny Ko
2012 Nov 26
2
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC The current 3.2 code branch has events being broadcast from the MCJIT engine
2012 Nov 26
1
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
I see. If I am writing my own listener can I still get back the (llvm::Function, void* Code, size_t Size)? Ciao. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:24 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC No. It adds a new event,
2012 Nov 26
4
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT
2012 Nov 26
0
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
The current 3.2 code branch has events being broadcast from the MCJIT engine when a new object is emitted, but the profiling listeners do not do anything with the events (and I don't expect they will before the 3.2 release becomes official). I have implemented some code in trunk since the 3.2 branch to traverse the emitted object and pick out named functions in the IntelJITEventsListener. An
2016 Dec 29
1
Interest in integrating a linux perf JITEventListener?
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
2013 Nov 13
3
[LLVMdev] Stack traces from JIT code
We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some
2017 Feb 02
0
Interest in integrating a linux perf JITEventListener?
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
2013 Mar 03
2
[LLVMdev] Profiling LLVM JIT code
Hey guys, I am currently working on a project that uses JIT compilation to compile incoming user requests to native code. Are there some best practises related to profiling the generated code? My project uses gperftools pprof for profiling etc. Is there a way to hook the two up? Are there any other profiling method that works? This page describes how to debug JIT code with GDB. I wonder if
2013 Nov 13
2
[LLVMdev] Stack traces from JIT code
Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew
2014 Jun 24
2
[LLVMdev] Any way get debug output of generated assembly from MCJIT without completely redoing CodeGen?
Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: >
2013 Mar 04
0
[LLVMdev] Profiling LLVM JIT code
Hi Priyendra, There is support for oprofile and Intel(r) VTune(tm) Performance Analyzer, but either one needs to be explicitly turned on during the build process. If you use MCJIT (as opposed to the older JIT) then oprofile support isn't in place yet. Both of these work by providing a JITEventListener that receives notification when new code is emitted and hooks it up to the profiling tool
2014 Nov 29
2
[LLVMdev] oprofile support?
Mi Maurice, A follow up to Andy's comments: MCJIT can find line numbers for ELF files, at least in limited circumstances. I know because I broke the regression test for it while doing some cleanup recently. ;) Looking at lib/ExecutionEngine/OProfileJIT/OProfileJITEventListener.cpp, I see the line: // TODO: support line number info (similar to IntelJITEventListener.cpp) >From a glance at
2013 Mar 05
1
[LLVMdev] Profiling LLVM JIT code
Thanks for the info. I am using old JIT. So that should not be a problem. I will take a look at using oprofile. I have never used it - so will be somewhat of a learning curve. I notice that the configure script has a --with-oprofile option. In addition to enabling that, is there something else that also needs to be done? My copy of LLVM is compiled with --enable-optimized. Will --with-oprofile
2012 May 24
1
[LLVMdev] JITEventListener destructor location
Hello, I've recently finished moving a cross-platform project to LLVM 3.0 and now transitioning to 3.1. One of the things I've hit is on OS X, I have linker errors involving JITEventListener and I've noticed if I move the JITEventListener destructor out of JIT.cpp and into JITEventListener.h (like other functions of JITEventListener), the linker is much happier. I'd like to push
2013 Nov 13
0
[LLVMdev] Stack traces from JIT code
>From NotifyObjectEmitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc:
2013 Nov 12
2
[LLVMdev] Stack traces from JIT code
[Resending this email after subscribing to the group. Got an error message the previous time around] Hey guys, In our project we have the following workflow: - Given a user request, we construct a C++ program to service the request - We create a compiler invocation to compile that program into an IR module - We use JIT (and optionally MCJIT) to convert the IR into executable code and run it