search for: inteljitevents

Hi all, I am experiencing a problem with the libraries IntelJITEvents and OProfileJIT They are listed in the `llvm-config --libs all` output but they are not present in the lib install directory. I am using git, revision 153741. Am I missing something ? Is this a known issue ? Thanks, Alberto

...e being, would be to ignore those two missing libraries. Thanks, Dan -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alberto Magni Sent: Friday, March 30, 2012 11:36 AM To: LLVM Developers Mailing List Subject: [LLVMdev] Missing IntelJITEvents and OProfileJIT libs Hi all, I am experiencing a problem with the libraries IntelJITEvents and OProfileJIT They are listed in the `llvm-config --libs all` output but they are not present in the lib install directory. I am using git, revision 153741. Am I missing something ? Is this a known issue...

...ng libraries. > > Thanks, > Dan > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alberto Magni > Sent: Friday, March 30, 2012 11:36 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] Missing IntelJITEvents and OProfileJIT libs > > Hi all, > > I am experiencing a problem with the libraries IntelJITEvents and OProfileJIT They are listed in the `llvm-config --libs all` output but they are not present in the lib install directory. > I am using git, revision 153741. > > Am I missing s...

...nt to take a look at > the (PGO-guided) Hot/Cold code splitting toolkit landing in LLVM just > few months ago. Although it takes static PGO profile, but I believe > you can leverage the static PGO framework in LLVM as foundation for > your dynamic profiling. >> >> I find IntelJITEvents in Execution Engine, is there any documentation >> on it's use cases? If you have thoughts over it, please share :) >> > I’d never used that, sorry >> >> Thanks >> > Best, > Bekket >> >> >> >> On 24/03/19 10:30 AM, Bekket McClane w...

...E/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld (maybe RuntimeDyld -> DynamicLoader ? Too direct?) But not sure this is really an accurate model for the logical layering of these libraries?

...#39;t really know the best bikeshed color here. Jim? > > My lame idea would be: > > ExecutionEngine -> JIT > ExecutionEngine -> JIT/Legacy > ExecutionEngine/MCJIT -> JIT/MC > ExecutionEngine/OProfileJIT -> JIT/OProfile > ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents > ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld > So long as we have the interpreter, we should keep the ExecutionEngine abstraction around. That said, I'd personally like to kill the interpreter… Eventually, lots of this can (and should) be simplified and flattened as the obsolete...

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...h() const { return Arch; } - /// getSubArch - get the parsed subarchitecture type for this triple. - SubArchType getSubArch() const { return SubArch; } - /// getVendor - Get the parsed vendor type of this triple. VendorType getVendor() const { return Vendor; } Index: lib/ExecutionEngine/IntelJITEvents/jitprofiling.c =================================================================== --- lib/ExecutionEngine/IntelJITEvents/jitprofiling.c (revision 212519) +++ lib/ExecutionEngine/IntelJITEvents/jitprofiling.c (working copy) @@ -30,7 +30,7 @@ #include "jitprofiling.h" -static const cha...

...(using ExecutionEngine::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

...(using ExecutionEngine::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 L...

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? >>

.../CMakeLists.txt b/lib/ExecutionEngine/CMakeLists.txt > index 2d9337bbefd..6092b4d1100 100644 > --- a/lib/ExecutionEngine/CMakeLists.txt > +++ b/lib/ExecutionEngine/CMakeLists.txt > @@ -26,3 +26,7 @@ endif( LLVM_USE_OPROFILE ) > if( LLVM_USE_INTEL_JITEVENTS ) > add_subdirectory(IntelJITEvents) > endif( LLVM_USE_INTEL_JITEVENTS ) > + > +if( LLVM_USE_PERF ) > + add_subdirectory(PerfJITEvents) > +endif( LLVM_USE_PERF ) > diff --git a/lib/ExecutionEngine/LLVMBuild.txt b/lib/ExecutionEngine/LLVMBuild.txt > index 9d29a41f504..b6e1bda6a51 100644 > --- a/lib/ExecutionE...

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 from JIT code Hi Andy, In the NotifyObjec...

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

...(using ExecutionEngine::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 slow...

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

...hot code functions than information from their intermediate representation because of the dynamic nature of compiled/interpreting source language. This make me focus more runtime profilers than analysis on IR. Of course, analysis from IR will be useful in start phase of JIT compilation. I find IntelJITEvents in Execution Engine, is there any documentation on it's use cases? If you have thoughts over it, please share :) Thanks On 24/03/19 10:30 AM, Bekket McClane wrote: > Hi, > > This idea sounds pretty cool > Just some quick comments inlined below: > >> On Mar 23, 2019, at...

2012/11/22 Chandler Carruth <chandlerc at google.com>: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... -> llvm/lib/IR/... > > I've

Hello LLVM & Clang hackers! Based on a discussion with Chris, I would like to propose a Great Renaming of Things for the 3.3-era LLVM and Clang codebase. First and foremost, the two most significant changes I would like to make: 1) llvm/lib/VMCore/... -> llvm/lib/IR/... I've discussed potential names for the VMCore (or LLVMCore) library with lots of folks, and the best idea anyone