similar to: [LLVMdev] "This is not a register operand" assertion during code generation with the MCJIT engine for arm

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

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

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

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 Oscar, Óscar Fuentes wrote: > Paul Melis <llvm at assumetheposition.nl> writes: > > [snip] > > Thanks! Fixed. > > BTW, bug reports are welcome. > It seems that the llvm-config generated when building through CMake does not contain -lpthread on my 32-bit Core2Duo Gentoo Linux system (even though I configured with LLVM_ENABLE_PTHREADS). I get missing symbols

Currently the LLVMbugs list only receives emails when a new bug is filed or an existing bug gets finally resolved. The gcc-bugs list on the other hand receives an email for every new comment in bugzilla. This leads to much better transparency, because you can easily see which bugs are currently being worked on; while the current LLVMbugs setup left you totally in the dark. So my suggestion would

>>> You shouldn't have to add new classes to the .td file, just modify >>> printOp for your asmprinters. >> >> I dont think printOp is virtual and therefore cannot be overriden ? > > Why does it need to be virtual? No 'intel' printers want % signs. The GAS intel code generator generates percents, look at the X86InstrInfo.td file it is full of

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"

Test Cases: (attached) Iteration code: (...) typedef TarjanSCC_iterator<CallGraph*> MyTarjan; CallGraph& callGraph = getAnalysis<CallGraph>(); MyTarjan iter = tarj_begin(&callGraph); MyTarjan end = tarj_end(&callGraph); while(iter!=end) iter++; (...) if you take the time to print out the function each non-looping node iter traverses, it never reaches main...

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

LLVM, What do I pass into the DSG in order to access the globals vector of functions that a function pointer may be calling. The code: CallInst *calli = dynamic_cast<CallInst*>(*i); std::vector<GlobalValue*> funcVect = theGraph.getNodeForValue(calli->getCalledFunction()).getNode()->getGlobals(); Doesn't appear to work... getCalledFunction() returns 0 Dave On Fri, 6 Dec

On Tue, 12 Jul 2005, Aaron Gray wrote: >>>> You shouldn't have to add new classes to the .td file, just modify >>>> printOp for your asmprinters. >>> I dont think printOp is virtual and therefore cannot be overriden ? >> Why does it need to be virtual? No 'intel' printers want % signs. > > The GAS intel code generator generates percents,

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

This came up when trying to compile the Python bindings against llvm 1.7. File include/llvm/Transforms/Scalar.h declares llvm::createPREPass(), which does not seem to be implemented anywhere. Should I report this in llvmbugs? -- Pertti

Hi, I supplied a patch for http://llvm.org/bugs/show_bug.cgi?id=15079 last year, then recently pinged llvmbugs but I guess that mail was lost in the moderation queue. Is it possible to accept or reject the patch on this issue, please? Thanks for your help, Graham. -------------- next part -------------- An HTML attachment was scrubbed... URL: