similar to: [LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)

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,

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

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

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 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 -

Guillermo, > 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. ARM JIT is broken in many ways. So, what you're seeing is

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

> 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? Currently, our project relies on LLVM 2.8 ARM JIT. I would like to know if we can move to MC JIT seamlessly. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems

On Aug 31, 2011, at 12:04 AM, James Molloy wrote: > 3.0 has been branched already AFAIK Not at all. :) -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110831/ca708102/attachment.html>

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

On Aug 31, 2011, at 12:19 AM, James Molloy wrote: > Apologies, thought I saw talk a while back about the branch on the list! :/ > I think you did, but the person was in error. :-) 3.0 won't branch until we get close to the release date, which hasn't been set yet. -bw

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>

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

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,

On Fri, Jul 8, 2011 at 9:30 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 07/ 8/11 05:26 PM, Eli Friedman wrote: >> >> Given that revision range, the only remotely likely culprit is 131463. >>  Which basically means that it "broke" because the default target >> features changed. > > And you are right here. 131463 == 131464 which is

On 07/ 8/11 05:26 PM, Eli Friedman wrote: > Given that revision range, the only remotely likely culprit is 131463. > Which basically means that it "broke" because the default target > features changed. And you are right here. 131463 == 131464 which is buggy. 131462 is OK. Thanks, Karel

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 target platform, but if I choose ARM, I hit an assertion in include/llvm/CodeGen/MachineOperand.h:260 (This is not a register operand). I am not sure if an older post regarding this assertion are relevant to my problem (

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

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

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