similar to: [LLVMdev] What are addSimpleCodeEmitter for?

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

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

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 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. :-)

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

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()

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > 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

Sorry i really forgot to mention one thing. I downloaded the X86 binaries of llvm+clang and llvm-gcc from llvm download site. i hope that is not a debug build. Prasanth J On Sun, Nov 15, 2009 at 1:22 PM, Prasanth J <j.prasanth.j at gmail.com> wrote: > Hi all, > > LLVM is built without debug enabled. Also i am not forcing lli to use > interpreter mode. so i dont think the

On Sep 1, 2009, at 12:07 PM, David Greene wrote: > So LLVMTargetMachine.cpp adds lots of transformation passes in the > various addPasses* routines. We'd prefer not to run all of these > things (LSR, for example). We've sort of dealt with it for now but > we'd really like to be able to turn some of these things off in a > convenient way. > > We could just

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

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

Done! Sandeep, this is really a great change. I had seen the discussion of it but hadn't looked at the details until now. Thanks a lot for contributing this. While I was reviewing it, I found some a few small nit-picky things to clean up (mostly in comments and whitespace). Sorry -- I'm a bit compulsive that way! I will commit those changes in a few minutes. Other than

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

On Apr 16, 2009, at 2:52 AM, Sandeep Patel wrote: > After wasting an inordinate amount of time trying to get test-suite to > run on arm-apple-darwin so I could reproduce your results, attached is > a patch that fixes the small copy&paste error of having 8-byte > alignment for stack-allocated f64s instead of the proper 4-byte. I've > updated the patch to the top of trunk

Sorry I haven't gotten back to you earlier. I have been busy. I ran some MultiSource/Benchmark earlier today. Looks like there are some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/ consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and sim. Are you able to test them on your end? Evan On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: > This time with

Sorry left a small bit of cruft in ARMCallingConv.td. A corrected patch it attached. deep On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > Sure. Updated patches attached. > > deep > > On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:

On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: > /// Information about how the value is assigned. > - LocInfo HTP : 7; > + LocInfo HTP : 6; > > Do you know why this change is needed? Are we running out of bits? HTP was't using all of these bits. I needed the hasCustom bit to come from somewhere unless we wanted to grow this struct, so I