[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