search for: mcjit

On 06/18/2012 07:21 PM, 陳韋任 (Wei-Ren Chen) wrote: > make check-all LIT_ARGS=--param=jit_impl=mcjit Thanks. When I run this on x86 ubuntu, there are 47 failures. Failing Tests (47): LLVM :: ExecutionEngine/MCJIT/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/MCJIT/2003...

On Mon, Jun 18, 2012 at 04:56:53PM -0700, reed kotler wrote: > I don't see any tests in either test or test-suite for -use-mcjit. For ARM, we need to manually switch to use mcjit, say $ make check-all LIT_ARGS=--param=jit_impl=mcjit Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.e...

I think you mean to say: make check-all LIT_ARGS=--param=jit_impl=use-mcjit On 06/18/2012 08:24 PM, reed kotler wrote: > On 06/18/2012 07:21 PM, 陳韋任 (Wei-Ren Chen) wrote: >> make check-all LIT_ARGS=--param=jit_impl=mcjit > Thanks. > > When I run this on x86 ubuntu, there are 47 failures. > > Failing Tests (47): > LLVM :: ExecutionEngine/M...

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?

Below is an outline of various usage models for MCJIT that I put together based on conversations at last month's LLVM Developer Meeting. If you're using or thinking about using MCJIT and your use case doesn't seem to fit in one of the categories below then either I didn't talk to you or I didn't understand what you're doing....

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding MCJIT in this mailing list, and I understand it tha...

Specifically, the test is causing a link to occur for CGO stuff. It has been running 8 minutes now with Gold, and is producing a 400mb .o file afaict: % du -hs /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o 397M /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o What am I doing wrong here? -------------- next part -------------- An

After re-cmaking and rebuilding everything from scratch, I'm seeing failures in MCJIT. It this something known or expected? I build LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". Example failure: /w/bld/org/./bin/lli -remote-mcjit -mcjit-remote-process=/w/bld/org/./bin/lli-child-target /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll -- Exi...

With Julia, we're obviously very much in the first use case. As you know, we pretty much have a working version of Julia on top of MCJIT, but there's still a few kinks to work out, which I'll talk about in a separate email. One think which I remember you asking at the BOF is what MCJIT currently can't do well that the old JIT did, so I'd like to offer up an example. With the old JIT, I used Clang to do dynamic code...

On Dec 9, 2013, at 11:08 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Below is an outline of various usage models for MCJIT that I put together based on conversations at last month’s LLVM Developer Meeting. If you’re using or thinking about using MCJIT and your use case doesn’t seem to fit in one of the categories below then either I didn’t talk to you or I didn’t understand what you’re doing. > > In any case,...

...entry is not) - retained memory use is critical -- ok to use much mem while JITing, but once we've reduced it to callable machine code function, we want to reclaim as much as possible of the memory needed by LLVM. - app is multithreaded and does not want to lock on a single MCJIT -- ok to have multiple MCJIT's, one per app thread, needing to run simultaneously. I'm currently using the old JIT, but would happily switch to MCJIT if its speed (especially ability to lazily compile functions as the old one can) were to improve and memory was as good. (Here...

...ion-level "dynamic linker"/memory manager, supporting function replacement with low-overhead JMP stubs. Now 1) is clearly a problem of code duplication. I'm not sure why a different emitter was created for the JIT but it would seem it's possible to reuse the lib/MC code just like MCJIT does. 2) takes much code all over the JIT code and at least for my use case it could just be removed. If 1) and 2) are solved and removed we are left with the (relatively small) "dynamic linker"/hack code only. I'd say the way this linker/loader works is much better fit for use cases...

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm...

Hi Pawel, Some of the issues I have come across (from memory!) are * MCJIT doesn't work on Windows, because it doesn't support COFF. If you want to use it on Windows you have to either target Mach-O (not clear whether that will work in general) or ELF (need to get a patch from Intel to be able to use this). * Make sure you include MCJIT.h and link in MCJIT.lib...

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #if...

Thu Jul 12 03:42:12 CDT 2012, Verena Beckham verena at codeplay.com : > I would not say it is trivial, having done it myself. > > MCJIT also doesn't support multiple modules, and it does not do JITing > on demand, instead, it does all of it at the same time in the > constructor (unless that is what you call "not lazy"). > So depending on how you've written your code there is some significant > reshuffl...

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE:...

On Wed, Sep 19, 2012 at 12:42:18AM +0000, Kaylor, Andrew wrote: > It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. > > Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The test...

Hi Dave, To confirm - I have no plans to remove MCJIT. I don't want to change any >> behavior for existing clients. The new stuff is opt-in. >> > > Why not? We did work to remove the legacy JIT in favor of MCJIT for the > usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to > then go back to maint...

...ry to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also invalidates the code cache. Even so, this will likely only work in cases where code generation is only invoked once. You are correct that MCJIT won't work in this case because of the function-by-function approach used in the Kaleidoscope example. Basically, with MCJIT once code has been generated for a module nothing else can be added to the Module. Making Kaleidoscope work with MCJIT would require introducing some sort of scheme whe...