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

Chris Lattner clattner at apple.com
Wed Jul 15 23:27:30 PDT 2009


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.

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 believe that aligning this  
work with Daniels work to make the targets more modular would be  
straight forward.  Are you willing to do this?

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.  However,  
I still don't understand why you're unwilling to make the CodeEmitter  
be a virtual base class instead of a template!

-Chris



More information about the llvm-commits mailing list