[llvm-commits] [patch] CodeEmitter Memory Foot Reduction

Aaron Gray aaronngray.lists at googlemail.com
Thu Jul 16 01:41:12 PDT 2009


Sorry, I reply to group too...

2009/7/16 Chris Lattner <clattner at apple.com>

> On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote:
>
>> Chris,
>>
>> If you/we do not like this code, then the alternatives are :-
>> 1) Leave as is, which I would not suggest.
>> 2) Revert to using MachineCodeEmitter like mechanics with virtual extend()
>> method to allow rebuffering with ObjectCodeEmitter providing the memory
>> management.
>> 3) Don't really know of any other alternatives :)
>>
>> 2 maybe the best compromise option. Its easy to code, removes templating
>> from the CodeEmitters, and is virtually transparent to our other DOE work.
>> The only thing it does not write via a BinaryObject object, so we loose that
>> functionality.
>>
>
> Hi Aaron,
>
> I'm sorry for not getting back to you sooner.  I work fairly LIFO and the
> craziness that has happened since your emails have distracted me.


Okay.


>
> One problem with this patch is that (for example) X86TargetMachine.cpp
> refers to the "createX86ObjectCodeEmitterPass" symbol, which forces the code
> emitter to object code emitter to be linked into the X86 target module.
>  There is still no way to create a JIT without two copies of the code
> emitter template.


I see, I have missed that :(

>I believe that aligning this work with Daniels work to make the targets
more modular would >be straight forward.  Are you willing to do this?

Whats Daniels approach, does he have any online documentation or code, do
you have an email address so I may talk to him.

>This patch keeps around the templates, which I really don't like.  However,
this is better >than what is in mainline, so it seems like a reasonable step
to me if you really really want >to do this.

No if it does not work without having to go thurther and mess with
TargetMachine's then its not solved what it is set out to solve.

I did some 'stats' for if it had worked :-

pre-doe at 72630
    AlphaCodeEmitter.o         23,155 Bytes
    ARMCodeEmitter.o      71,125 Bytes
    PPCCodeEmitter.o      31,629 Bytes
    X86CodeEmitter.o      39,313 Bytes
doe at 72631
    AlphaCodeEmitter.o          32,642 Bytes
    ARMCodeEmitter.o           158,219 Bytes
    PPCCodeEmitter.o            42,380 Bytes
    X86CodeEmitter.o            81,491 Bytes
doe at 72631+opt
    AlphaCodeEmitter.o          14,300 bytes
    AlphaJITCodeEmitter.o        9,103 bytes
    AlphaMachineCodeEmitter.o    9,216 bytes

    ARMCodeEmitter.o             2,499 bytes
    ARMJITCodeEmitter.o         88,454 bytes
    ARMMachineCodeEmitter.o     89,499 bytes

    PPCCodeEmitter.o            17,896 bytes
    PPCJITCodeEmitter.o         14,239 bytes
    PPCMachineCodeEmitter.o     14,364 bytes

    X86CodeEmitter.o            46,909 bytes
    X86JITCodeEmitter.o         46,858 bytes

>However, I still don't understand why you're unwilling to make the
CodeEmitter >be a virtual >base class instead of a template!

The basic idea of using templates inconjunction with inlining is for
efficiency.

6,500 virtual calls outputting bytes out of 10000 calls, and the rest 1,750
being words to output 10KBytes of code does not entice me to use virtual
calls.

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090716/160fe572/attachment.html>


More information about the llvm-commits mailing list