similar to: [LLVMdev] Multiple modules JITting

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Mikhail Lyapunov > Subject: [LLVMdev] Multiple modules JITting > We're looking for a way to use LLVM to JIT many modules, assuming that > the full list of modules and their content are not available at a time > when some of jitted pieces are already in use. We do this in our

Hi, Attempting to use LLVM in jitting mode for AMD64, we met a problem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when

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,

Hi, I met troubles with jitting x86 codes when using Intrinsic::x86_sse_ldmxcsr. The target code must execute some SSE2 instruction with DAZ/FTZ modes enabled and others with DAZ/FTZ disabled. I'm trying to get this by emitting LDMXCSR instructions with proper flag words. It appeared however that execution engine sometimes reorders these instructions with computational ones (say with

Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable code, use a JITEventListener to grab each function and copy it to my own memory, let all the LLVM stuff die normally then use my copy of the code. However when I call setRelocationModel(Reloc::PIC_) on the engine builder I get code that seg faults. The assembly looks

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

I'm not sure I see why the delegating memory manager feels wrong to both of you. That's exactly the kind of usage model I would envision for clients that needed to handle multiple ExecutionEngines that had reason to share a memory manager. I'm saying this as an invitation to discussion, not to be argumentative. We certainly could change things if it would make the design better.

It seems wrong to delegate a dozen or more methods when I only want to change the behavior in a couple small ways. It would have been easier to derive a class, but the base class is inaccessible (in an anonymous namespace). And I was afraid to roll my own memory manager because I didn't understand what all those methods do. So MCJIT is future - will JITMemoryManager remain relevant? If so I

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

Hi Andy, One of the issues that I found not intuitive, is that when an ExecutionEngine is deallocated, the memory manager's destructor is also called. This resulted in having to write two objects in my case, one as a per JIT request memory manager and one global JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

Hi Dirkjan, Are you using JIT or MCJIT? Cheers. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Saturday, March 23, 2013 8:18 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Hi Andy, One

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As all "external" functions are provided by the language's FFI mechanism, it does MyExecutionEngine->DisableSymbolSearching(); MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them

I am implementing ELFObject class for MCJIT to be able to run ELFs on ELF-platforms. One thing bothers me: I see that the RTDyldMemoryManager-based allocator is always passed to MCJIT and to RuntimeDyld classes from outside. This enforces the approach that memory will be allocated function by function with startFunctionBody/endFunctionBody. This maybe was good for the old JIT, but not for

Hi David, Following up on the problems we discussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. This patch makes three changes: 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block

On 07/06/2011 08:28, Jim Grosbach wrote: > Hi Yuri, You're correct that the current JITMemoryManager interface > isn't a very good fit for the MCJIT. For the time being though, the > intent is to work with it as much as possible so that the MCJIT can be > a drop-in replacement for the old JIT. If we change the > JITMemoryManager API right off the bat, we'll make it

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. Code model, relocation model and and memory manager are whatever default for this - did not modify. The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function: A+1; A*B.t(); where A and B are

Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work. I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If the patch works when memory is loaded below 2GB then it would be possible

Following up and expanding on an earlier conversation, I'd like to discuss making several non-trivial changes to the MCJIT engine and related objects. There may be some interdependencies between these changes, but I think that they can be logically grouped as follows: * Lazy module compilation * Enhance the JIT memory manager interface to enable section-based memory protection * Clean up