search for: usemcjit

...17 September 2014 08:43, Anton Smirnov <dev at antonsmirnov.name> wrote: > i've changed lli arguments to the next (instead of default): > > return llvm_interpret( > InputFile, > std::vector<std::string>(), > false, // ForceInterpreter > false, // UseMCJIT > [...] > Now i'm having: > > Unhandled instruction encoding format! > UNREACHABLE executed at > /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547! This one at least is understandable. Your options imply (I couldn't find any "llvm_in...

...name> wrote: >> > i've changed lli arguments to the next (instead of default): >> > >> > return llvm_interpret( >> > InputFile, >> > std::vector<std::string>(), >> > false, // ForceInterpreter >> > false, // UseMCJIT >> > [...] >> > Now i'm having: >> > >> > Unhandled instruction encoding format! >> > UNREACHABLE executed at >> > >> /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547! >> >> This one at le...

I've also tried the next combination: true, // ForceInterpreter false, // UseMCJIT and ios app just crashed with no output 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hey. > > I've checked out LLVM/Clang 3.5 and modified my static libs source code to > use the latest llvm/clang sources. > Also i'm trying triple ""...

...be to > get MachO/ARM fully supported in MCJIT. > > Regards, > Lang. > > > On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <dev at antonsmirnov.name> > wrote: > >> I've also tried the next combination: >> true, // ForceInterpreter >> false, // UseMCJIT >> and ios app just crashed with no output >> >> 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >> >>> Hey. >>> >>> I've checked out LLVM/Clang 3.5 and modified my static libs source code >>> to use the lates...

...gt;>> Lang. >>> >>> >>> On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <dev at antonsmirnov.name> >>> wrote: >>> >>>> I've also tried the next combination: >>>> true, // ForceInterpreter >>>> false, // UseMCJIT >>>> and ios app just crashed with no output >>>> >>>> 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>> >>>>> Hey. >>>>> >>>>> I've checked out LLVM/Clang 3.5 and modified...

I found the following problem when I try to debug "target does not support mc emission" in linux (the same code executes OK in windows): Below is a snippet extracted from this method, if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel, AllocateGVsWithCode, TM); if (EE) return EE; } else if (ExecutionEngine::JITCtor) { ExecutionEngine *EE...

I see very strange behaviour. I am linking to LLVMMCJIT and I #include MCJIT.h. I can see in the debugger that MCJIT::Register is being called. If I break in ExecutionEngine::create, I can see that UseMCJIT is true and ExecutionEngine::MCJITCtor is non-zero. Still at this point (lines after 481): if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, AllocateGVsWithCode, TheTM.take(...

...things -- such as profiling -- that fail purely because the default old JIT doesn't work. So a consensus has been reached that the best way forward is to try to make the MCJIT the default for ARM-Linux-EABI and see if that's workable.) Looking at the lli source code, there's the option UseMCJIT that defaults to false. You can also use -use-mcjit, -use-mcjit=true, -use-mcjit=false. Things would be fine if we could make the option default architecture dependent. However, these defaults are all set-up BEFORE we commit to what architectural triple we're using (as the target triple can be...

...things -- such as profiling -- that fail purely because the default old JIT doesn't work. So a consensus has been reached that the best way forward is to try to make the MCJIT the default for ARM-Linux-EABI and see if that's workable.) Looking at the lli source code, there's the option UseMCJIT that defaults to false. You can also use -use-mcjit, -use-mcjit=true, -use-mcjit=false. Things would be fine if we could make the option default architecture dependent. However, these defaults are all set-up BEFORE we commit to what architectural triple we're using (as the target triple can be...