similar to: [LLVMdev] mcjit

Hi Pawel, Some of the issues I have come across (from memory!) are * MCJIT doesn't work on Windows, because it doesn't support COFF. If you want to use it on Windows you have to either target Mach-O (not clear whether that will work in general) or ELF (need to get a patch from Intel to be able to use this). * Make sure you include MCJIT.h and link in MCJIT.lib, otherwise (even if

On Jul 11, 2012, at 6:04 AM, Benjamin Kramer wrote: > > On 11.07.2012, at 14:39, Reed Kotler <rkotler at mips.com> wrote: > >> Does anyone know which projects rely on mcjit? >> >> There is the oldjit too; it's still being used? > > The most prominent user of the MC JIT is probably LLDB. > > The only issue with MCJIT I know of is the lack of

Can I assume we're talking about MCJIT since a file format and relocations are involved? Some changes are required in order to get MCJIT to generate ELF object files. Eli Bendersky submitted a patch some time ago to modify the target triple code to enable this, but after a bit of discussion there didn't seem to be a consensus for accepting this proposal. If you want to try it out, the

Hi Jim, Andrew, Thanks, I read the discussions about using ELF + MCJIT + Windows and was hoping MachO would work just as well. Since you don't need to modify LLVM to be able to output MachO this was my first choice. But are you saying MachO will not work as well as ELF? Thanks for the patch Andrew, that will have to be my plan B in this case. Verena On 29/06/2012 23:47, Kaylor, Andrew

Hi there, I wondered whether anyone could give me any advice about counting assembly instructions when using MCJIT? For performance regression testing I would like to be able to count the number of instructions generated during the jit compilation of a given module. The Statistic class, as far as I understand, cannot collect this data per-module (per-ExecutionEngine/per-MCJIT), and there is

Hi Verena, Windows + MachO is likely to run into lots of problems once you start passing in non-trivial code. The relocation model is very tied to Darwin. I believe some folks doing JIT on Windows have had some success w/ ELF. Hopefully someone more familiar with the specifics of that will chime in. -Jim On Jun 29, 2012, at 8:58 AM, Verena Beckham <verena at codeplay.com> wrote: >

Hi Verena, I think that we can count the number of instructions with "-stats" command line option. As you mentioned, this option uses Statistic class like "STATISTIC(EmittedInsts, "Number of machine instrs printed");" I don't know exactly about parallel code generation environment but this option seems like to work correctly in common case as following. This is

Hi, In X86MachObjectWriter::RecordX86Relocation I found the comment if (Target.isAbsolute()) { // constant // SymbolNum of 0 indicates the absolute section. // // FIXME: Currently, these are never generated (see code below). I cannot // find a case where they are actually emitted. Type = macho::RIT_Vanilla; } Is the FIXME still true? I've got some code that

Hi, I found that prologue_end markers where badly placed in my test, and applied https://reviews.llvm.org/D41762 in the hope that it would fix it (I'm on 4.0.1). However, this fix doesn't work for VLIW architectures. At this point we're iterating over bundles, not MachineInstructions, and the FrameSetup flag is set on MachineInstructions, not bundles. If bundling happens in the

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be

Hi, anyone know anything about copy propagation? Matthias, I see this was your code originally? Was there some assumptions you made? I'm hitting an assertion in MachineCopyPropagation::isNopCopy: if (Src == PreviousSrc) { assert(Def == PreviousDef); return true; } This code compares two COPY instruction to see whether they are effectively "the same". The assert assumes

Hi, You cannot call removeModule on a JIT with no modules: jitstate will be 0 and therefore we have a null-pointer exception. The function returns a boolean for success/failure, however, so you would expect to be able to call it and get false back. Should we be checking for jitstate != 0 before accessing the variable? - if (jitstate->getModule() == M) { + if (jitstate &&

Does anyone know which projects rely on mcjit? There is the oldjit too; it's still being used? Thanks. Reed

On 11.07.2012, at 14:39, Reed Kotler <rkotler at mips.com> wrote: > Does anyone know which projects rely on mcjit? > > There is the oldjit too; it's still being used? The most prominent user of the MC JIT is probably LLDB. The only issue with MCJIT I know of is the lack of windows support, and I expect oldjit to go away once that is sorted out. Switching between the JIT

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

While using MCJIT, when I define a function with name Fn_.._lib_rc-variant.lp0_17_0x706970 ExecutionEngine::getPointerToFunction fails to locate it (returns 0). There is no problem if the function is named Fn_0x706970. There is no problem with those names using the traditional JIT. Is there any special limitation on function names for MC/MCJIT?

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the