search for: jit

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-202004...

Hi. I am trying to run LLVM with JIT on ARM processor (Android phone). Currently I have problems using external functions. Any call to external function crashes and gives me signal 11 (SIGSEGV) at some random address. I'm trying to run following C code: *** extern void add1(int* x); int main() { int a = 10; int b = 20;...

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on MachineCodeEmitter and the GVStub methods. Also the fact...

Hi Jeffrey, Thanks for pointing me in the right direction ! I'm not using the JIT in lazy mode, but it was fun to understand the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of...

...test.tar.gz >>> >>> Thanks for the help. I apologize in advance if it turns out I'm doing >>> something stupid! >>> >> >> I hope you realise that by running llvm-ld without -native you are >> actually >> executing your program from the JIT. I did a native compilation as >> follows: >> used llvm-link to link all of the bitcode into "total.bc"; ran llc on >> total.bc, >> producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to >> work: >> >> $ ./...

Thanks for the patch! I'll clean this up, convert your sample to a unit test, and commit it for 2.7. On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > Hi Jeffrey, > > Thanks for pointing me in the right direction ! > I'm not using the JIT in lazy mode, but it was fun to understand the > lazy-stub code. > > Attached you will find a patch which follow your 1st option : a map > Stub_address -> JITResolver instance, except that the used map is a > "std::map" to apply the same upper_bound trick as in the map &...

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is...

...is up, convert your sample to a > unit test, and commit it for 2.7. > > On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: > > Hi Jeffrey, > > > > Thanks for pointing me in the right direction ! > > I'm not using the JIT in lazy mode, but it was fun to understand the > > lazy-stub code. > > > > Attached you will find a patch which follow your 1st option : a map > > Stub_address -> JITResolver instance, except that the used map is a > > "std::map" to apply the same upper_bo...

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static DenseMap<stub_addr...

Hi folks! I am currently involved in project which uses LLVM JIT and I have a couple of questions for you: 1) According to http://llvm.org/Features.html LLVM JIT supports only X86 and PowerPC, but LLVM code generator supports ARM too. Are there any plans for JIT to make support also for ARM backend? 2) Could LLVM JIT collect some hot traces from overall code an...

While the MCJIT doesn't cover all of the features the old JIT had, it has the huge advantage of actually producing working results on ARM and PPC64. The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for simple examples. I'm proposing to remove the JIT code emitters for the ARM a...

Hello, I am currently working with PPC64 JIT support for LLVM. So far I could make function calls work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' just after 'sys::Memory::InvalidateInstru...

...look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out to be a semicomplex > modification because of the JITInfo classes dependance on > MachineCodeEmitt...

...prefer correct but slow behavior by > default, and explicitly enabling dangerous (but in some cases fast) > behavior. The behavior is only dangerous because people are using it in new and different ways. > > I would also point out that it seems that most of the people new to > the JIT are surprised by the current behavior, where as those who > would be surprised by needing to enable lazy JIT are those long > familiar with past behavior. In the OSS world, I always favor easing > adoption over maintaining the status quo. This argues for better documentation. I'd pref...

Hi Garrison, I finally come back from holidays and take time to watch your patch. I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? I thought about JIT and modules, and I wonder if we don't need to take it another way. Now we can create multiples JIT. What if we decide to simplify the JIT in allowing only one module per instance of JIT ? It will simplify greatly the code of the JIT. If we need to jit 2 differents modules, we can create 2 JITs...

Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Ciao, Duncan. > I am currently working with PPC64 JIT support for LLVM. So far...

...e it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native compilation as follows: used llvm-link to link all of the bitcode into "total.bc"; ran llc on total.bc, producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to work: $ ./total __l_personality called$ Of course it is probably suppos...

Hi, all It seems PPC JIT does not recognize inline assembly. For example, when I give LLVM IR belows to PPC JIT, %0 = tail call i32* asm "", "={r10}"() nounwind ; <i32*> [#uses=1] it complaints that inline assembly is not a supported instruction. x86 JIT works fine, however. Is there a re...

...of a patch, which I recently attached to bug 2606, whose original version was modified to reflect the lists comments. Also please note the comment at the end of this email, which basically questions whether this bug is really a bug. 1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found "external" GlobalVariable. 2) To solve the foreign Module Function problem, I modified JIT.{h,cpp} to emit a stub for a found "external" Function instance, when that foreign Module defined Function has not y...

Hi James, Note that the wiki example is a manual JIT example that works directly with the C++ APIs. As you know, no LLVM tools are used, just LLVM libraries. I say this to point out, that in the example, the exception mechanism is under the complete control of the developer moded by the LLVM libraries. In my mind a different example/different doc....