similar to: [LLVMdev] Can LLVM jitter emit the native code in continuous memory addresses ?

It is possible to subclass JITMemoryManager and pass in a custom memory manager, but I don't believe you'll be able to convince the JIT to emit PIC code without hacking on LLVM a bit. Reid On Sun, Jun 26, 2011 at 4:21 AM, Mohammed Ag <admirer4 at gmail.com> wrote: > ** > > I have question relating to LLVM Jitter: Can i obligue the LLVM Jitter to > emit the native

Thx again Evan for the review. Here's a new patch for the JIT in itself. The major changes are: 1) A JITMemoryManager now has a flag saying "I require to know the size of what you want to emit" 2) DwarfJITEmitter is augmented with GetSize* functions 3) JITEmitter::startFunction checks if the JITMemoryManager requires to know the size. If so, it computes it and gives it through the

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

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

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

Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the

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 Apr 16, 2008, at 1:46 AM, Nicolas Geoffray wrote: > >> >> How about a default GetInstSize() as well? Return 1 for every >> instruction except for some special TargetInstrInfo instructions, >> e.g. >> PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But >> perhaps we can default most targets to it? >> >> > > I

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

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

I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how LLVM addresses this issue. Thanks, Josh --------------

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

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

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 is true, freed memory should be

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons

Folks, Is anyone else the failure below? On Mac OS X everything builds properly... Thanks for any help, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 27.png Type: image/png Size: 18959 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081217/e7d37fee/attachment.png>

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

Hi, Can you please clarify? 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. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires

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