similar to: [LLVMdev] Being able to know the jitted code-size before emitting

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

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, 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

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.

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 Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > Hi, I found a bug in the code that generates exception tables, I've attached > what I think is the correct fix. > > When you run out of space writing to a buffer, the buffer management code > simply stops writing at the end of the buffer. It is the responsibility of > the caller to

Eric Christopher wrote: > > On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > > > > Hi, I found a bug in the code that generates exception tables, I've attached > > what I think is the correct fix. > > > > When you run out of space writing to a buffer, the buffer management code > > simply stops writing at the

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

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

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

In my quest to account for memory, I've now come to the in-memory IR, and the generated code. I want to book the generated code memory against the agent that is generating the code. I see that LLVM's Function class [1] has a size function; what does this represent and can I use it to account for the space used by the in-memory IR? As for generated code, the JIT [2] class simply returns a

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

On Sep 28, 2007, at 10:27 AM, Sandro Magi wrote: > In my quest to account for memory, I've now come to the in-memory IR, > and the generated code. I want to book the generated code memory > against the agent that is generating the code. > > I see that LLVM's Function class [1] has a size function; what does > this represent and can I use it to account for the space used

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?