similar to: [LLVMdev] [cfe-dev] exc_bad_instruction on arm

Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 And i will also try using MCJIT. 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hi, Tim. > > I've used Clang 3.4 final release and now i'm going to test it with 3.5 > release (since i've read about arm64 improvements). > I will report my results. > > BTW, is it possible to get smth like

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

Hi, Lang. Thanks for clarification. I will check out current branch tomorrow and report you back. Most likely i will create bug issue with cleaned sources for static lib and test ios app. Actually i'm not professional c++ dev so my question is - is there any chance to do the next: 1. compile .cpp code to .ll code (seems i already did it) 2. interpret .ll file by any supported at the moment

Hi, Lang. 2014-09-19 0:39 GMT+06:00 Lang Hames <lhames at gmail.com>: > Hi Anton, > > I don't follow what you're asking? > > For (1): You can compile c++ files to .ll files with clang - it seems like > you've already worked that out. > > For (2): What do you mean "supported at the moment"? In the 3.5 release > MCJIT is known to be broken for

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,

Hi, Would it be possible to make the following slight change to ExecutionEngine::create()? I would like to be able to disable the automatic enumeration of loaded modules, and the subsequent searching for undefined symbols (using SearchForAddressOfSymbol). I propose adding an extra parameter to the function definition, defaulting to true. static ExecutionEngine *create(ModuleProvider *MP,

On Jul 22, 2009, at 5:23 PM, Chris Lattner wrote: > > On Jul 22, 2009, at 1:32 PM, Dan Gohman wrote: > >>>> >>>> - A null pointer is associated with no addresses. >>>> >>> >>> A null pointer in address space 0. >> >> I'm not fond of weird address-space semantics, but for consistency >> with what the optimizer is

Hi Rob, Can you comment on exactly what the problem is you want to solve? Is it a performance issue with LoadLibraryPermanently, or do you simply not want the external symbols to be resolved from within the JIT? - Daniel On Wed, Jul 22, 2009 at 11:22 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > On Jul 22, 2009, at 9:43 PM, Rob Grapes wrote: > >> Hi, >> >>

Hi, I'm looking into making MCJIT the default for the ARM-Linux-EABI target for lli. (WHY? the old JIT doesn't really work on ARM, and in particular there are some regression tests of interesting 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

On Jul 22, 2009, at 9:43 PM, Rob Grapes wrote: > Hi, > > Would it be possible to make the following slight change to > ExecutionEngine::create()? > > I would like to be able to disable the automatic enumeration of > loaded modules, and the subsequent searching for undefined symbols > (using SearchForAddressOfSymbol). > > I propose adding an extra parameter to

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 =

Hi Daniel, In my case ExecutionEngine::create() loads 40 modules, then each time I try to resolve a symbol that I know is in a DLL that I supply, it looks through all 40 modules first. This is on Windows, so I get the following modules loaded: ntdll.dll, kernel32.dll, USER32.dll, GDI32.dll, SHELL32.dll, ADVAPI32.dll, RPCRT4.dll, Secur32.dll, msvcrt.dll, SHLWAPI.dll, ole32.dll, OLEAUT32.dll,

On Mon, Jun 22, 2009 at 4:43 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 22, 2009, at 2:19 PM, Kasra wrote: > > Hi, > > for some reason I could not get the machine code generator for x86 > working. The interpreter is the only thing that works, is there > anything that I am missing here? > > This recently changed.  In your main program, please

ExecutionEngine::create() can return NULL with an empty error message (admittedly, it did so because of global variable initialization problems). The code currently lets NULL go through if ErrorMsg is empty, and segfaults later. When EE is NULL but ErrorMsg is empty, simply do not try to print it and exit. Index: tools/lli/lli.cpp

Hello all, I'm trying to bring an LLVM-based project that is working on Linux up on Win32. I am having problems with llvm::ExecutionEngine::create returning a NULL. I traced it to these lines: // Unless the interpreter was explicitly selected, try making a JIT. if (!ForceInterpreter && JITCtor) EE = JITCtor(MP, ErrorStr); // If we can't make a JIT, make an

It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of JIT and MCJIT is already a bit of a mess, and changing the default to MCJIT

On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > (thanks to Reid, who gave nice advice) the fibonacci function code > works now. Please find attached file. > > but... the performance is adequate, say, for byte-code > interpretation mode and not for optimized JITing. > fibonacci function of 35 from attached file is more > then 100 times slower then the following code compiled

Hi all, (thanks to Reid, who gave nice advice) the fibonacci function code works now. Please find attached file. but... the performance is adequate, say, for byte-code interpretation mode and not for optimized JITing. fibonacci function of 35 from attached file is more then 100 times slower then the following code compiled with "gcc -O2" : ----------- #include <iostream> int

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases

Hi everyone, I am getting into the ARM specific relocation for MC/ELF, and have some questions There are some x86/arm specific relocation values already, before they are lowered down to ELF reloc types (i.e. ARMRelocations.h and X86Relocations.h) As near as I can figure it, the relocation constants in (ARM|X86)Relocations.h are used only in ARMCodeEmitter, and X86CodeEmitter.cpp respectively -