search for: inteljiteventlistener

...nEngine::RegisterJITEventListener) that MCJIT will call with a copy of the actual object image that gets generated. You could then write that image to a file as a basis for comparing the generated code. You can find a reference implementation of the interface in lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp. Thanks I'll have a look. > > -Andy > Stéphane

Yeah, take a look at the IntelJITEventListener code (in lib/ExecutionEngine/IntelJITEvents). It uses the debug info to find function names. -Andy From: Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces...

...de isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing an ObjectImage reference as the parameter to the listener. The only current listener I'm aware of is the IntelJITEventListener, which wants to notify the Intel VTune Amplifier (if present) about the newly JITed functions. The listener uses the ObjectImage interface (which is modeled after the ObjectFile interface) to walk through the symbols in the object and look for functions, getting their address and size from the Sym...

...nEngine::RegisterJITEventListener) that MCJIT will call with a copy of the actual object image that gets generated. You could then write that image to a file as a basis for comparing the generated code. You can find a reference implementation of the interface in lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stéphane Letz Sent: Thursday, July 18, 2013 11:20 AM To: Eli Friedman Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLVM 3.3 JIT code speed Le 18 juil. 2013 à 19:0...

...IT 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 IntelJITEventListener, I think it would be easy to copy the line number support in there over to OProfileJITEventListener. Cheers, Lang. On Fri, Oct 17, 2014 at 3:04 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > The fact that you are getting line...

...ot; comment. :) > ** > > Right now, when MCJIT emits an object image, it broadcasts an event to any > registered listeners indicating that an object was emitted, passing an > ObjectImage reference as the parameter to the listener. The only current > listener I’m aware of is the IntelJITEventListener, which wants to notify > the Intel VTune Amplifier (if present) about the newly JITed functions.*** > * > > ** > OK. > ** > > > > The problem is that I have a test case that is trying to reference an > inlined function. In this case, the generated object puts th...

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

Le 18 juil. 2013 à 19:07, Eli Friedman <eli.friedman at gmail.com> a écrit : > On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >>

...nEngine::RegisterJITEventListener) that MCJIT will call with a copy of the actual object image that gets generated. You could then write that image to a file as a basis for comparing the generated code. You can find a reference implementation of the interface in lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp. > > Thanks I'll have a look. >> >> -Andy >> > > Stéphane > And since the 1) DSL ==> C/C++ ===> clang/gcc -03 ===> exec code chain has the "correct" speed, there is no reason the JIT based one should be slower right? So I still...

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an

...I made the "non-alloc" comment. :) Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing an ObjectImage reference as the parameter to the listener. The only current listener I'm aware of is the IntelJITEventListener, which wants to notify the Intel VTune Amplifier (if present) about the newly JITed functions. OK. The problem is that I have a test case that is trying to reference an inlined function. In this case, the generated object puts the 'inlined' function in a separate section (I'm not c...

Hi Andy and Andrew, I am very interested in this discussion as our co. have critical components that are dependent on the old JIT. We have implemented support for MCJIT mostly to get AVX support. The difference in module support is forcing us to duplicate a module when we want to JIT the same bitcode with different parameters. We also have code that depends on the JITEventListener API.

I've been trying to get oprofile results for jitted code without success. I built an 3.5.0 llvm with oprofile enabled, and tested it with lli on a small test case. I built the latest oprofile from the git repository. Debugging I can see that lli is registering the listener and making the oprofile calls to the libopagent api to specify the names and address ranges of jit'd routines, and