[llvm-commits] [patch] Minor X86CodeEmitter Memory Foot Reduction

[Aaron Gray]

> We need to revisit the approach. Templatizing the CodeEmitter class is 
> probably not the right way to go Sorry I didn't think hard about this 
> when the patch landed back the end of May. Chris' recent "machine  code" 
> work is obsoleting at least object code emitter so I'll let him  comment.

I have put alot of work into getting this far. My designs are really 
dependant upon this approach and it yeilds the fastest code emission at base 
level. All my subsequet code is really based on this approach. Chris know 
about the DOE development, and the designs have been on the Wiki for some 
time.

Templating and using inline methods allow the fastest approach to the actual 
code emission. Its nice clean and efficient code, that allows bespoke usage 
of the code generator backend, for the JIT and Object Module emission.

Aaron

> Evan
>
> On Jul 6, 2009, at 12:53 PM, Bruno Cardoso Lopes wrote:
>
>> On Mon, Jul 6, 2009 at 4:11 PM, Evan Cheng<evan.cheng at apple.com>  wrote:
>>> Sorry, I am missing some context. Why is each of the emitter a  separate
>>> template instantiation in the first place? Why can't the code in
>>
>> This happens because ObjectCodeEmitter is a lot simpler than 
>> JITCodeEmitter and
>> we don't need to deal with CurrBufferBegin, GVStub*, and so on.
>>
>>> X86CodeEmitter.cpp be shared across all 3?
>>
>> I agree with Evan, I don't see why this code shouldn't be shared,
>> besides that, putting
>> all that code in a header file doesn't seems like the right approach.
>>
>> -- 
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>