similar to: EH Data for MC JIT compiled methods

Yes, the GDB-jit registration stuff got pulled out (perhaps prematurely). That said, even without function names, it's still useful to have the EH bits so that gdb can unwind through the JIT'ed frames. Otherwise gdb (and glibc's backtrace() function, valgrind, etc) end up stopping the unwind prematurely, usually at the first JIT'ed frame. Combined with trivial use of the

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

> test/ExecutionEngine/MCJIT is currently a duplicate of test/ExecutionEngine, which runs the tests with MCJIT. So it already runs every time you "make check" (on build-bots too!). The duplication is unfortunate, but hopefully temporary - once the LIT SUBTEST patch gets in (it's been in review for ages now, ahem ;-) ) it should be gone and each test in test/ExecutionEngine will

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of reed kotler > Sent: Tuesday, June 19, 2012 02:57 > To: ll >> "llvmdev at cs.uiuc.edu" > Subject: [LLVMdev] mc jit > > I don't see any tests in either test or test-suite for -use-mcjit. > > Are we not testing this yet? >

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

We are currently using the JIT (non-MC) to implement a REPL-like shell that needs to run in a long-lived process. During development, we noticed substantial memory-growth with increased lifetime of the JIT. In trying to eliminate that continuous memory growth, we did a few things, including making LLVMContext collect and free unused constants (detected by Value::uses_empty()). This dropped

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

Some boring style comments: - whack trailing whitespace - spaces, not tabs - the methods in MCJITStreamer.cpp should probably have blank lines between them There seems to be an ownership problem of the MCJITObjectWriter. If I understand the code correctly, the assembler Finish method takes ownership of the Writer parameter, which presumably is needed to JIT two functions. +1 for separate

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

On Jun 24, 2011, at 12:44 PM, Yuri wrote: > On 07/19/2010 05:14, Olivier Meurant wrote: >> Together with Jan Sjodin (in copy of this email), we begin an >> implementation of the JIT with MC. The idea, suggested by Jan, is to >> develop a MCJIT in parallel of the current JIT and to keep the two >> implementations until (at least) the new MC one is mature enough. >>

Hi, I'm wondering about the status of Windows x64 unwind info in LLVM. We're trying to print a simple stack trace on Windows exceptions, including function names of JITted code (which we can roughly derive using addresses from a JITEventListener). While this works fine in 32-bit mode, we're unable to properly walk the stack in 64-bit since the unwind info doesn't seem to be

> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.

On Jun 29, 2011, at 4:36 PM, Yuri wrote: > On 06/24/2011 13:23, Jim Grosbach wrote: >>> Any progress with this? >>> gitorious page shows the last update on Jul 27, 2010. >>> >> There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and

> So... there is no way to make throw and catch working in a jitted code > under Windows? > I have used throw and catch in jitted code, so "no way" is too strong. But there's a large range of possible states between "no way" and "always enabled OOTB". Currently, this is pretty close to the "mostly unimplemented" side of the spectrum in LLVM.

On Mon, Jun 18, 2012 at 08:49:20PM -0700, reed kotler wrote: > I think you mean to say: > > make check-all LIT_ARGS=--param=jit_impl=use-mcjit Hrm, I was told that I can use LIT_ARGS=--param=jit_impl=mcjit. Does yours make those failures go away? :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

Hi LLVM folks, Attached with this email, you will find a patch not directly applicable (it doesn't compile like this) which (try to) enhance the structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer

On 07/19/2010 05:14, Olivier Meurant wrote: > Together with Jan Sjodin (in copy of this email), we begin an > implementation of the JIT with MC. The idea, suggested by Jan, is to > develop a MCJIT in parallel of the current JIT and to keep the two > implementations until (at least) the new MC one is mature enough. > Currently code is kept on gitorious >

Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =

On 06/24/2011 13:23, Jim Grosbach wrote: >> Any progress with this? >> gitorious page shows the last update on Jul 27, 2010. >> > There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and ExecutionEngine/MCJIT. > > It's usable enough for some things; for

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?