similar to: [LLVMdev] Global variables on LLVM JIT on ARM (Android)

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

Is MC JIT support expected in 3.0, and if not, what does the timeline look like? Would I be better off trying to get the supported but incomplete MC JITter working than spending effort preserving the dead branch? Thanks Craig On Aug 30, 2011, at 4:44 PM, James Molloy wrote: > Hi Craig, > > > The problem with this is that the ARM JIT was never gotten to "supported"

Hi Craig, The problem with this is that the ARM JIT was never gotten to "supported" status at any point, so regressions were not monitored. The code path is essentially dead, at the moment, with noone willing to invest time in flogging a dead horse as it'll all have to be rewritten when MC lands properly and someone has the time/inclination to architect it. I understand your

Hello all, When using the JIT on ARM, I get the following error message. The code works fine on both X86 32 and 64 bit architectures. rbx: /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260: unsigned int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. Program received signal SIGABRT, Aborted.

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 -

On Aug 30, 2011, at 3:12 PM, Owen Anderson wrote: > The non-MC-based ARM JIT path is known not to work, and nobody is working on fixing it. The MC-based instruction encoder is rapidly maturing is generally passable for static encoding, but the MCJIT is still in its infancy. I was relying on this support in LLVM 2.8, and while it is definitely incomplete, it does work if you don't depend

Craig, On Aug 30, 2011, at 12:51 PM, Craig Smith wrote: > I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. > I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) The non-MC-based ARM JIT path is known not to work,

Hi all, I was wondering if anyone could help me out with my MCJIT bug on LLVM 3.2. The same code works beautifully on x86 desktop with the same version of LLVM. This is the error I've been getting on ARM platforms: dsheffie at tegra-ubuntu:~/projects/threeFingeredJack/python_compile$ python ./vvadd.py [ 0. 0. 0. ..., 0. 0. 0.] ARMCodeEmitter::emitPseudoInstruction UNREACHABLE

I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) 1) VFP/Neon instructions don't encode correctly at al, because the encoding methods generated by tablegen for them

Hello, So the current JIT will be superseded by the MCJIT completely and no further development should be expected for the current JIT? In any case, I am definitely interested in submitting a patch if you could help me by sending me in the right direction, since I really want this working. I managed to reproduce this behavior in LLVM 3.0 by modifying llc to read my .bc file and try to JIT the

Note that you are *not* using MCJIT. The backtrace shows lib/Target/ARM/ARMCodeEmitter.cpp, with is part of the old JIT. On 15 May 2013 08:24, Jonas Zaddach <zaddach at eurecom.fr> wrote: > Hi, > > I have a small example program that is supposed to generate cross-compiled > JIT code with the MCJIT execution engine on an x86 host. The code works fine > if I choose x86 as

Hi Anton, I've added the llvmdev list, since the issues you're seeing are coming from the backend, which is more their side. On 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,

Hello, This problem happens in ToT under specific conditions - namely there is a big BB#671 basic block of code the just copies data from memory location to another. At the beginning of BBB#671 r0 is loaded from the jumptable in the constant pool immediately after it. Displacement from the pc in this case is #1476 which is way above magic #1020 hence the error after fixup. Both

I can look at this, but you'll need to send the .bc file. Please open a PR? There have been lots of bugs in ARMConstantIslands where it's off by 1, but I haven't seen one where it's off by a lot like this. On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote: > Hello, > > This problem happens in ToT under specific conditions - namely there > is > a big

I hope to make Xcode my primary debugging tool for LLVM, but there's just one quirk in an otherwise wonderfully working IDE. Using Xcode 4.5 with clang 3.0, I'm unable to set a breakpoint in any TableGen-generated .inc files. I notice Xcode doesn't do syntax highlighting either, despite explicitly setting the filetype in the "Identity and Type" window. I can see that

This is the JITCodeEmitter patch, this is to facilitate cordening off the JIT code from the future direct object emission code (i) supporting the upcoming ObjectCodeEmitter class, on the X86, ARM, Alpha, and PowerPC platforms. This involves generic parameterization of backend code emitters to allow code emission to allotted class types, JITCodeEmitter and ObjectCodeEmitter.

On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote: > On 8/18/2010 12:39 PM, Dale Johannesen wrote: >> I can look at this, but you'll need to send the .bc file. Please >> open a PR? > > I would do it but I am in a bit of a pickle as the .bc is from > propriety code and > I can not post it. Can't help much then. You might look into obfuscating the

On 8/18/2010 12:39 PM, Dale Johannesen wrote: > I can look at this, but you'll need to send the .bc file. Please open > a PR? I would do it but I am in a bit of a pickle as the .bc is from propriety code and I can not post it. Anyway, I have been trying to re-create the problem in a simpler test case. Since, I do not have access to the source for the .bc I am trying to guess the

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

Hi, I'm sorry I forgot to mention I am compiling the bitcode using the JIT. The actual error, I get when I'm trying to get the function to the pointer. I'm using a custom front end that translates Android's Dalvik bytecode into LLVM bitcode based on Android ICS's modified LLVM version. Thanks, On Mon, Feb 20, 2012 at 7:55 PM, James Molloy <James.Molloy at arm.com>