search for: allocategvswithcode

...emission" in linux (the same code executes OK in windows): Below is a snippet extracted from this method, if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel, AllocateGVsWithCode, TM); if (EE) return EE; } else if (ExecutionEngine::JITCtor) { ExecutionEngine *EE = ExecutionEngine::JITCtor(M, ErrorStr, JMM, OptLevel, AllocateGVsWithCode, TM); if (EE) return EE; } Both ExecutionEngine::MCJITCtor...

The patch looks good to me. But we cannot allow AllocateGVsWithCode to be initialized to be false yet. Can you add a mechanism to define the behavior when the JIT is created / initialized? Also, I am not crazy about this being moved to JITMemoryManager.h. This seems like implementation detail that should be kept hidden. + // If the PoisonMemory parameter i...

Hi, In ExecutionEngine.cpp, when the JIT or the Interpreter have not been linked in then EngineBuilder::create fails without setting ErrorStr. I've attached a patch to fix this. Warm Regards KS Sreeram -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ee-not-linked-in-msg.diff URL:

...:create, I can see that UseMCJIT is true and ExecutionEngine::MCJITCtor is non-zero. Still at this point (lines after 481): if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, AllocateGVsWithCode, TheTM.take()); if (EE) return EE; } else if (ExecutionEngine::JITCtor) { ExecutionEngine *EE = ExecutionEngine::JITCtor(M, ErrorStr, JMM, AllocateGVsWithCode, TheTM.take()); if (EE) return EE; } The second if-branch is being exec...

On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> wrote: > The patch looks good to me. But we cannot allow AllocateGVsWithCode to > be initialized to be false yet. Can you add a mechanism to define the > behavior when the JIT is created / initialized? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an EngineBuilder? > Also, I am not crazy about this being moved t...

...> be executed, and references from one buffer to another won't work in > that environment.  So that model needs to continue to work.  If you > want to generalize it so other models work as well, go ahead. Maybe what I should do then is change TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and invert the meaning, since I feel like most users probably just want malloc or something similar. You could then subclass the appropriate TJI class and override that method. Would that be a reasonable API change? No one else calls or overrides that method. In order to do that we'd also n...

...references from one buffer to another won't work in >> that environment.  So that model needs to continue to work.  If you >> want to generalize it so other models work as well, go ahead. > > Maybe what I should do then is change > TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and > invert the meaning, since I feel like most users probably just want > malloc or something similar.  You could then subclass the appropriate > TJI class and override that method.  Would that be a reasonable API > change?  No one else calls or overrides that method.  In order to do...

...n the original .cpp file that was turned into bitcode. * Traditionally, I have created a JIT execution engine like this: m_llvm_exec = llvm::ExecutionEngine::createJIT (module(), err, jitmm(), llvm::CodeGenOpt::Default, /*AllocateGVsWithCode*/ false); All has worked fine, this is a system that's seen heavy production use for a couple years now. Now I'm trying to make this codebase work with MCJIT, and I've run into some trouble. Here's how I'm setting up the ExecutionEngine for the MCJIT case: m_llvm_exec =...

On Jul 2, 2009, at 5:20 PM, Reid Kleckner wrote: > On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> The patch looks good to me. But we cannot allow AllocateGVsWithCode >> to >> be initialized to be false yet. Can you add a mechanism to define the >> behavior when the JIT is created / initialized? > > That makes four optional arguments to ExecutionEngine::create. Do you > mind if I go ahead and add an EngineBuilder? Please, thanks....

Sorry I am late to the thread. I've been meaning to find the time to respond properly. 1. Yes, the default behavior is to keep GV and function in the same memory buffer. The reason is the JIT can be used in a client and server environment. This makes it possible without doing expensive relocation on the fly. In fact, the currently implementation doesn't allow the client to do

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

> We have been JITing kernels and having a memory manager for globals > would be a big win there (clean up a few hacks to make things go in > the correct locations). I'm also guessing that Dale's client at Apple is using a custom memory manager, since without doing that there's no way to get the size of the code block in order to send it over the wire. Adding an

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