similar to: [LLVMdev] Heuristic for choosing between MCJIT and Interpreter

On 08/11/2014 04:21 AM, David Chisnall wrote: > Hi Josh, > > On 9 Aug 2014, at 21:33, Josh Klontz <josh.klontz at gmail.com> wrote: > >> I'm facing a situation where I have generated IR that only needs to be executed once. I've noticed for simple IR it's faster to run the interpreter on it, but for complex IR it's much better to JIT compile and execute it.

Is the MCJIT infrastructure supported on Windows? I'm getting an "LLVM ERROR: Incompatible object format!" when running my project with both VS 2013 and Mingw_w64 (GCC 4.8.2). Looks like this issue has been brought up before [1,2] and the answer is "almost". Any help would be greatly appreciated. v/r, Josh [1]

Bingo, thanks! Confirmed it works for both 32- and 64-bit targets. Should `sys::getProcessTriple()` be updated with this change? According to the documentation: /// getProcessTriple() - Return an appropriate target triple for generating /// code to be loaded into the current process, e.g. when using the JIT. I had to "-elf" to the result of this function for JIT to work on

Greetings, I have a simple C++ EDSL working using the JIT execution engine. When I upgraded to LLVM 3.2 (effortless upgrade, awesome stuff!) I thought I would try taking the MCJIT for a spin after having read that the JIT is considered to be "legacy". So the changes I made to my code were: + #include <llvm/ExecutionEngine/MCJIT.h> - #include <llvm/ExecutionEngine/JIT.h> +

As Yaron said, you need to add "-elf" to the end of your target triple to get MCJIT to generate ELF object in memory on Windows. This should work with 32- or 64-bit targets. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Joshua Klontz Sent: Monday, December 02, 2013 1:18 PM To: Dev Subject: [LLVMdev] MCJIT + Windows = Incompatible

As of LLVM 3.2, is it possible to use iostream with the MCJIT or interpreter execution engines? I'm getting some errors... Each of these commands correctly prints "hello": echo -e '#include <stdio.h>\nint main(){ printf("hello"); }' | clang -cc1 -emit-llvm-bc -x c++ | lli -use-mcjit echo -e '#include <iostream>\nint main(){ std::cout <<

Hi everyone, I was happily using MCJIT for over a year until yesterday when I created a function call with an argument of a struct type. That caused a crash in SelectionDAG around DataLayout::getAlignment(). I remember the noise about the DataLayout started being mandatory. But I cannot find precise information. Should I set the DataLayout in every Module created? Where can I get the

On 12 November 2013 21:10, Josh Klontz <josh.klontz at gmail.com> wrote: > Porting my project from JIT to MCJIT did not fix the code generation bug > Frank is also experiencing. However, Renato's "-avx" suggestion did resolve > the issue for me. Hopefully we can get some traction on this bug, happy to > help where possible! > Hi Josh, Frank, Glad to see you

On 12 November 2013 16:05, Frank Winter <fwinter at jlab.org> wrote: > engineBuilder.setMCPU(llvm::sys::getHostCPUName()); > Try: engineBuilder.setMAttrs("-avx"); --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/4b00aed7/attachment.html>

Porting my project from JIT to MCJIT did not fix the code generation bug Frank is also experiencing. However, Renato's "-avx" suggestion did resolve the issue for me. Hopefully we can get some traction on this bug, happy to help where possible! v/r, Josh -- View this message in context: http://llvm.1065342.n5.nabble.com/Limit-loop-vectorizer-to-SSE-tp63175p63205.html Sent from the

So I thought I'd write this down, in case anyone has useful input to it or wants to read up on the decisions later. Currnetly swfdec compiles actions from a flash file into JSScript objects and executes them using the standard Spidermonkey API. While this allows all the niceties that are available with SpiderMonkey (most important: a whole debugging framework with stack inspection etc - see

For what it's worth, I'm also experiencing this same issue. If there is interest I can provide some very simple reproducible test cases, but I was planning on moving to MCJIT this week anyway. -- View this message in context: http://llvm.1065342.n5.nabble.com/loop-vectorizer-JIT-AVX-segfaults-tp63089p63115.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ?

On Nov 15, 2013, at 12:36 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 15 November 2013 20:24, Joshua Klontz <josh.klontz at gmail.com> wrote: > Agreed, is there a pass that will insert a runtime alignment check? Also, what's the easiest way to get at TargetTransformInfo::getRegisterBitWidth() so I don't have to hard code 32? Thanks! > > I think

Yes, I was just about to send out: DL->getABITypeAlignment(ScalarDataTy); The question is: “… ABI alignment for the target …" is that getPrefTypeAlignment or getABITypeAlignment I would have thought the latter. On Nov 15, 2013, at 4:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Arnold Schwaighofer"

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.com> > To: "Joshua Klontz" <josh.klontz at gmail.com> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 15, 2013 4:05:53 PM > Subject: Re: [LLVMdev] Limit loop vectorizer to SSE > > > Something like: > > index

Nadav, I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to vectorization. I can't tell if it's the loop vectorizer or the codegen at fault, but the alignment assumption seems to sneak in somewhere. v/r, Josh [1]

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM,

A fix for this is in r194876. Thanks for reporting this! On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>