search for: memorymanagement

Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface

Hi Joseph, There are several reasons that a client might want to access the object before it's loaded, so a general API like #2 seems like the way to go. To support this in MCJIT you can add this to the event listener API. Orc clients can already do this by adding a custom object-file layer. - Lang. On Fri, May 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com> wrote:

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks,

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

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > >> So I (think I) found a bug in the JIT: >> http://llvm.org/bugs/show_bug.cgi?id=4483 >> >> Basically, globals used by a function are allocated in the same buffer >> as the first code that uses it.  However, when you

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

Hi Lang, thanks for announcing. Would be great if you could send another short notice as soon as the actual patch exists. Best, Stefan Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev: > Hi All, > > I'm going to be making some API breaking changes to the ORC APIs, and > to the RuntimeDyld class (which underlies MCJIT). The changes may > affect MCJIT clients but are unlikely

On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote: > On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> > wrote: >> >> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: >> >>> So I (think I) found a bug in the JIT: >>> http://llvm.org/bugs/show_bug.cgi?id=4483 >>> >>> Basically, globals used by a

...DN_FIELD=1 -DBASE64_NEEDS_SESSION_DATA=1 -I/usr/local/include > > -fpic -g -O2 -c enums.c -o enums.o > > gcc -std=gnu99 -I/home/mkimpel/R_HOME/R-patched/R-build/lib64/R/include > > -DHAVE_LIBIDN_FIELD=1 -DBASE64_NEEDS_SESSION_DATA=1 -I/usr/local/include > > -fpic -g -O2 -c memoryManagement.c -o memoryManagement.o > > memoryManagement.c: In function 'RCurl_releaseManagerMemoryTickets': > > memoryManagement.c:143: warning: passing argument 1 of 'free' discards > > qualifiers from pointer target type > > gcc -std=gnu99 -shared -L/usr/local/lib64 -...

...DN_FIELD=1 -DBASE64_NEEDS_SESSION_DATA=1 -I/usr/local/include > > -fpic -g -O2 -c enums.c -o enums.o > > gcc -std=gnu99 -I/home/mkimpel/R_HOME/R-patched/R-build/lib64/R/include > > -DHAVE_LIBIDN_FIELD=1 -DBASE64_NEEDS_SESSION_DATA=1 -I/usr/local/include > > -fpic -g -O2 -c memoryManagement.c -o memoryManagement.o > > memoryManagement.c: In function 'RCurl_releaseManagerMemoryTickets': > > memoryManagement.c:143: warning: passing argument 1 of 'free' discards > > qualifiers from pointer target type > > gcc -std=gnu99 -shared -L/usr/local/lib64 -...

...).handler-block14470", label %"(TRY-0).dispatch-header19", !dbg !26 I’m getting this error when I throw a core::Unwind exception and I’m certain that there is a landing pad with that clause. libc++abi.dylib: terminating with uncaught exception of type core::Unwind ../../src/gctools/memoryManagement.cc:75 Trapped SIGABRT - starting debugger ABORT was called!!!!!!!!!!!! I’ve written a Common Lisp compiler that uses LLVM as the backend and it interoperates with C++ code and I use C++ exception handling for non-local exits. -------------- next part -------------- An HTML attachment was scrubbed...

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

Dears, I'm trying to call the function that defined in the host application from IR code, but LLVM is saying that there is no such function... I've seen the tutorial of Kaleidoscope, and defined the function as extern "C" { void test1(void) { cout << "test function in the host application \n" ; } } ...in the host application. Would you please let me give any

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get();

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute. I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules,

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

So I (think I) found a bug in the JIT: http://llvm.org/bugs/show_bug.cgi?id=4483 Basically, globals used by a function are allocated in the same buffer as the first code that uses it. However, when you free the machine code, you also free the memory holding the global's data. The address is still in the GlobalValue map, so any other code using that global will access freed memory, which