search for: startfunctionbodi

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

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

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

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 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 everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Hi, Two questions. 1) How are you computing size of the method being jitted? 2) Why not simply add the functionality of allocating emission buffer of specific size to MachineCodeEmitter instead? Thanks, Evan On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to

On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> 1) How are you computing size of the method being >> jitted? > > I add a new pass with addSimpleCodeEmitter, with the emitter being a > SizeEmitter. Since the target calls the emitter with functions such as > writeByte, writeWord, etc.... the SizeEmitter class implements these

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

Evan Cheng wrote: > > Let's see. ARM has it already. PPC has getNumBytesForInstruction so > you only need to add one to compute function size. Also you only need > to implement it for targets that support JIT right now, which leaves > Alpha and X86. I'm guessing Alpha is using fixed encoding so it should > be pretty easy. Or you can just punt it and let the target

Hi Matt, hi Bruno, I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? I seem to be unable to even get lli to run some code with the "use-mcjit" flag. I attached a test case that works fine for "lli y.bc" but exits with an error for "lli -use-mcjit y.bc": "LLVM ERROR: Unknown object format" If I call InitializeAllTargetMCs() before

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

On Apr 4, 2008, at 11:16 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Evan Cheng wrote: >> >> Let's see. ARM has it already. PPC has getNumBytesForInstruction so >> you only need to add one to compute function size. Also you only need >> to implement it for targets that support JIT right now, which leaves >> Alpha and X86. I'm

On Apr 4, 2008, at 5:50 AM, Nicolas Geoffray wrote: > Evan Cheng wrote: >> On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: >> >> >> That's a hack. :-) > > It is if you think that code emitter should only be used for actually > writing somewhere the data. It is not if you find it another useful > utility ;-) Except it's pretty slow at it. :-)

Hi Evan, Evan Cheng wrote: > > I don't think the duplication is going to be top much of a problem. If > it is, I'll bug you about refactoring. :) > > I don't mean to show how lazy I can be, but I also need to know the size of the exception table emitted in memory (JITDwarfEmitter.cpp). Reviewing it a little, I can not see how things won't be duplicated.

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

On Apr 7, 2008, at 3:02 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> I don't think the duplication is going to be top much of a problem. >> If >> it is, I'll bug you about refactoring. :) >> >> > > I don't mean to show how lazy I can be, but I also need to know the > size > of the exception table

On Dec 4, 2009, at 2:40 PM, Eric Christopher wrote: > So, on top of this it seems like a lot of the semantics have changed > after your patch. I'm certain the existing patch is wrong and that > we'll want a computation somewhat similar to the clang one that I > think Doug is going to post. > > I think the safe thing is to revert for now and we can discuss all