search for: getfunctionsize

Hi Evan, Evan Cheng wrote: > > Yeah, sorry I'm stubborn sometimes. :-) And really I think adding the > code size functionality is not really that complicated. I would be > happy to help if you run into issues. > > What do you think of adding a TargetMachine::getFunctionSize(MachineFunction*) and a TargetInstrInfo::getInstructionSize(MachineInstruction*)? Is this a good place to make them available to other passes? (ie the JIT) Thanks, Nicolas > Thanks. > > Evan >

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And yes, it's a good > idea, the...

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. > > What do you think? > > Nicolas > > > Evan Cheng wrote: >> >> I think both of these belong t...

...wrote: >> >> Yeah, sorry I'm stubborn sometimes. :-) And really I think adding the >> code size functionality is not really that complicated. I would be >> happy to help if you run into issues. >> >> > > What do you think of adding a > TargetMachine::getFunctionSize(MachineFunction*) and a > TargetInstrInfo::getInstructionSize(MachineInstruction*)? Is this a > good > place to make them available to other passes? (ie the JIT) I think both of these belong to TargetInstrInfo. And yes, it's a good idea, there are other passes which can make use o...

...ray 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() ARM::GetInstSize(). I'd > like to see them standardized (all targets that have JIT support can > accurately calculate the function / instruction sizes) and then you > can make use of that. > OK, I see. However this requires to do this to all targets. In my solution, it...

...ou 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. :-) > > >> Some targets already have ways to compute the exact >> size of a function. See ARM::GetFunctionSize() ARM::GetInstSize(). >> I'd >> like to see them standardized (all targets that have JIT support can >> accurately calculate the function / instruction sizes) and then you >> can make use of that. >> > > OK, I see. However this requires to do this to all ta...

...w, 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 maintainers > worry about it. > Yeah, fixed encoding like in PPC is easy to handle. > Really you only need to implement GetFunctionSize for X86 and that's > not as horrible as you think it is. For each instruction: > 1. Compute how many bytes of prefix. The code is there in > X86CodeEmitter except all you need is the size, not the prefixes being > emitted. > 2. For each instruction format, e.g AddRegFrm, MR...

...on is surely using things in a way that wasn't intended, >>>>> but it >>>>> works fine and for all targets. Is this really a stopper for >>>>> integrating >>>>> it? (You can see here my laziness on implementing the >>>>> GetFunctionSize to >>>>> every targets :)). >>>>> >>>>> Nicolas >>>>> >>>>> >>>>> >>>>>> It seems like you >>>>>> can add the functionality to MachineCodeEmitter rather than add a >>&...

...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 function is known. That's a hack. :-) Some targets already have ways to compute the exact size of a function. See ARM::GetFunctionSize() ARM::GetInstSize(). I'd like to see them standardized (all targets that have JIT support can accurately calculate the function / instruction sizes) and then you can make use of that. > > >> 2) Why not simply add the functionality of allocating emission >> buffer of sp...

...m guessing Alpha is using fixed encoding so it >> should >> be pretty easy. Or you can just punt it and let the target >> maintainers >> worry about it. >> > > Yeah, fixed encoding like in PPC is easy to handle. > >> Really you only need to implement GetFunctionSize for X86 and that's >> not as horrible as you think it is. For each instruction: >> 1. Compute how many bytes of prefix. The code is there in >> X86CodeEmitter except all you need is the size, not the prefixes >> being >> emitted. >> 2. For each instruction...

...t;>> My solution is surely using things in a way that wasn't intended, >>>> but it >>>> works fine and for all targets. Is this really a stopper for >>>> integrating >>>> it? (You can see here my laziness on implementing the >>>> GetFunctionSize to >>>> every targets :)). >>>> >>>> Nicolas >>>> >>>> >>>> >>>>> It seems like you >>>>> can add the functionality to MachineCodeEmitter rather than add a >>>>> new >&...

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