search for: armcodeemitt

...EST 'LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll' FAILED ******************** Script: -- /nfs_home/chenwj/test/native-build/arm2/Debug+Asserts/bin/lli /nfs_home/chenwj/test/llvm/test/ExecutionEngine/2003-01-04-ArgumentBug.ll > /dev/null -- Exit Code: 134 Command Output (stderr): -- ARMCodeEmitter::emitPseudoInstruction UNREACHABLE executed at /nfs_home/chenwj/test/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:831! 0 libc.so.6 0x402e5000 Stack dump: 0. Program arguments: /nfs_home/chenwj/test/native-build/arm2/Debug+Asserts/bin/lli /nfs_home/chenwj/test/llvm/test/ExecutionEngine/2003-01-04-Argum...

...ic 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 - and on X86 only materialized in the JIT case for the X86) Are these relocation values for X86 deemed to be kosher for MC? I was made curious by a comment in ARMBaseInstrInfo.h:166 saying that the ARMCodeEmitter should go away - Since this comment was descri...

...incomplete, it does work if you don't depend on certain features. I found it worked adequately as long as you set the -thumb2,-t2xtpk attributes. It would be nice if at least it didn't get further broken until the MC Emitter was fully ready to take its place. The first FIXME comment in ARMCodeEmitter seems to indicate this is a goal.: "… They are placeholders to allow this encoder to continue to function until the MC encoder is sufficiently far along that this one can be eliminated entirely." >> 1) VFP/Neon instructions don't encode correctly at al, because the encoding m...

...s naturally going to happen. Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Craig Smith [craig at ni.com] Sent: 30 August 2011 22:01 To: LLVM Developers Mailing List Cc: Owen Anderson Subject: Re: [LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn) 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 M...

...seeing incorrect output from the post-encoder hook, it's because the hook itself has a bug. > This looks like it would affect all targets, except apparently only ARM uses this feature. > > 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). This is another symptom of the non-MC ARM JIT being unmaintained. It is correct for emitPseudoInstruction() to assert. All pseudo instructions should be expanded before they reach the encoder, and they are...

...t; > James > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Craig Smith [craig at ni.com] > Sent: 30 August 2011 22:01 > To: LLVM Developers Mailing List > Cc: Owen Anderson > Subject: Re: [LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn) > > 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 encod...

...MI, Value);\n"; should be Case += " Value |= " + PostEmitter + "(MI, Value);\n"; This looks like it would affect all targets, except apparently only ARM uses this feature. 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). 3) FCONSTS/FCONSTD also assert similarly. emitMiscInstruciton which used to support these instructions was removed in r116644. If you try to add back a case for them in the obvious way, getBinaryCodeForIns...

...here's the GDB backtrace: #0 __libc_android_abort () at bionic/libc/unistd/abort.c:82 #1 0x40e35600 in llvm::llvm_unreachable_internal (msg=0x0, file=<optimized out>, line=<optimized out>) at external/llvm/lib/Support/ErrorHandling.cpp:98 #2 0x409d34ac in (anonymous namespace)::ARMCodeEmitter::getMovi32Value (this=<optimized out>, MI=<optimized out>, MO=<optimized out>, Reloc=8) at external/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:439 #3 0x409e237c in (anonymous namespace)::ARMCodeEmitter::emitDataProcessingInstruction (this=0x1a7a338, MI=..., ImplicitRd=0, Implic...

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

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

...x00151c62 in llvm::MachineOperand::getReg (this=<optimized out>) at /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260 #6 0x003d8998 in getReg (this=<optimized out>) at /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260 #7 (anonymous namespace)::ARMCodeEmitter::emitLoadStoreInstruction (this=0x74725b20, MI=..., ImplicitRd=3855757312, ImplicitRn=0) at ARMCodeEmitter.cpp:1171 #8 0x003dade2 in (anonymous namespace)::ARMCodeEmitter::emitInstruction (this=0x74725b20, MI=...) at ARMCodeEmitter.cpp:563 #9 0x003dc42e in (anonymous namespace)::ARMCodeEmit...

...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_interpret" function, so there's some guesswork) that you're using the old JIT. That's been discouraged for a while, and it's been removed completely now in trunk. It's...

...y 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 code for the mentioned Triple. The error: ARMCodeEmitter::emitPseudoInstruction UNREACHABLE executed at /home/guillermo/llvm-3.0.src/lib/Target/ARM/ARMCodeEmitter.cpp:838! Stack dump: 0. Program arguments: ./bin/llc -mtriple armv7a-unknown-linux-gnueabi -O3 /home/guillermo/Code/SieveAtom_execute.bc 1. Running pass 'ARM Machine Code Emitter' on...

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

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

...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 ARMCodeEmitter::emitLEApcrelJTInstruction() and emitJumpTableAddress() are responsible for the offending instruction adr r0, #.LJTI8485_1_1 But besides the fact that they do not complain about the invalid offset from the pc I do not see anything wrong here. The problem seems to be in the ARMConstantIslands...

...lp 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 executed at /home/dsheffie/llvm/llvm-3.2.src/lib/Target/ARM/ARMCodeEmitter.cpp:843! Stack dump: 0. Running pass 'ARM Machine Code Emitter' on function '@tramp_4002416' Aborted I'm running on Ubuntu 12.04 (hard float) on a quad-core nv...

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 (