similar to: [LLVMdev] Memory clean for applications using LLVM for JIT compilation

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

On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > I derived a class from JITMemoryManager which delegates everything to > an instance made with CreateDefaultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit ugly. Did you find any other > solutions? I ended up

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.

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

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

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

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > Yes, you should be able to inherit from

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

On Mon, Jan 14, 2013 at 4:56 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello all, > > I've already bothered people on IRC with this question and it was > recommended to ask it here. > > First of all, some context. In Rubinius (http://rubini.us/, > http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create > LLVM IR using the C++ API and

Hi Frank, I'm not sure I completely understand what your delegating memory manager is doing, but I probably don't need to. If your primary objection is that you can't derive from the DefaultJITMemoryManager then I personally wouldn't object to your submitting a patch to make that accessible as a base class. The future path for JIT and MCJIT is under debate. A few of us would

Hello all, I've already bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

Yeah, the JITMemoryManager appears to be owned by the EE and I cannot find a way to get around it. I agree from an API design point of view a custom mgr should be owned by the client code but that is not how it works right now. You probably have to copy out the JIT code into your own block of memory. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces

Mesa (http://www.mesa3d.org/) uses LLVM to compile shaders. These are typically small bits of code (~10KB) and one application can use many of them. Mesa creates an ExecutionEngine with a default JIT memory manager for each shader it compiles, and keeps the engine around as long as the shader code is needed. This results in memory waste of ~1MB for each shader. Half the overhead is in the

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

Hello, In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")). The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it

Right. glibc's amusing stance is that you setenv/putenv are not thread safe, but getenv is. I assume Ruby exposes setenv and therefore simply not calling setenv isn't an option. Would it solve your problems if all getenv() calls happened at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > >

Hi all, I'd like to ask about something I've been thinking about and haven't found a way to make this possible with LLVM, so I'm wondering whether I'm not looking properly or that indeed that can't be done currently. What I'm trying to do is to be able to modify generated assembly code after it has been created through LLVM. At this point the original LLVM IR

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Dirkjan Bussink > Subject: [LLVMdev] Modifying machine code after it's generated with LLVM > I'd need to be able to pass a memory address where the actual native > code is generated to this fallback function, but I haven't found any > ways of doing this. Perhaps I don't

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do