Reid, et.al,
I cannot post the JITCodeEmitter efficiency patch for commital yet as it is
still dependant upon the newer version of the MachineCodeEmitter being
submitted, when it is replaced by the ObjectCodeEmitter. Anyway I have
attached the code for you to look at. It is also a endian speedup patch for
included. The ObjectCodeEmitter patch should hopefully go in this weekend.
There are inline raw*emit mehods, these and the reserveBytes method are
intended on being used by the cpu *CodeEmitters so they just reserve the
maximum instruction length and then use the raw methods to do writing. These
and the endian speedup should help to make the raw mechanics of JIT code
generation a bit faster.
Aaron
2009/7/1 Aaron Gray <aaronngray.lists at googlemail.com>
> Right, good to here it needs some work. I did a patch that has not been
>>> applied yet that adds an extend() method to MachineCodeEmitter,
that gets
>>> called if there is a buffer overrun, it allows moving the buffer
code to
>>> a
>>> larger buffer, then it continues doing the overruning method and
returns
>>> normally.
>>>
>>
>> For the JIT? I was working on a patch to fix that. It sounds like
>> yours does a better job, since I was just going to try again with more
>> memory.
>>
>
> I'll look it out and get it freshend up.
>
> Bruno is sheduled to do this work on his GSoC, but it will not be
>>> completed
>>> until September.
>>>
>>> The next patch to go in will use the ObjectCodeEmitter rather than
the
>>> MachineCodeEmitter and output to ELF, so you maybe better waiting
for
>>> this
>>> to be done.
>>>
>>> We are really trying to neaten up this area. As soon as the ELF,
and
>>> MachO
>>> ObjectCodeEmitter patches go in I will be modifying the cpu
backends to
>>> put
>>> the Emitters in to header files and move the create functions that
>>> instatiate the templates into separate .cpp files so to remove the
code
>>> overheads on the resulting lcc and lli binaries. So you may then
add your
>>> own *CodeEmitter class to replace or inherit from
MachineCodeEmitter.
>>>
>>
>> Interesting. We'll see.
>>
>
> Okay :)
>
> Aaron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090702/2bb4a1a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Endian.h
Type: application/octet-stream
Size: 688 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090702/2bb4a1a2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JITCodeEmitter.h
Type: application/octet-stream
Size: 14492 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090702/2bb4a1a2/attachment-0001.obj>
