similar to: [LLVMdev] ARMCodeEmitter vs ARMMCCodeEmitter (ARM relocations for ELF)

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

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

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"

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,

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

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

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

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

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 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 all, I'm trying to extend the Dalvik VM to load some LLVM assembly from the SD card, JIT it, and execute it. I'm using AOSP 4.0.4, a Galaxy Nexus, and the version of LLVM that comes in the external project of AOSP (LLVM 2.8, I believe?) I have the following LLVM assembly: target datalayout =

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

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

Hello, I'm eager to get to know Clang+LLVM but I'm having some problems generating debug information that force llc.exe to crash. I'm running from the command-line on Windows 7 with clang+llvm versions 2.9 downloaded from the website. The input file is main.c:      void mainCRTStartup()      {      } This is compiled to intermediate with debug symbols using:      clang -g -O0 -c

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

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.

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