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

[Evan Cheng]

On Jul 6, 2009, at 3:07 PM, Aaron Gray wrote:

>> On Jul 6, 2009, at 2:56 PM, Aaron Gray wrote:
>>
>>>> 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.
>>
>> Hi Aaron, what part of your design talks about this?  What problem  
>> is templating this all solving?
>
> Templating allows us to have mutiple types of MachineCodeEmitters,  
> the JITCodeEmitter, and the ObjectCodeEmitter, and any other kind of  
> CodeEmitter we require in the future, e.g. Reid Kleckner'  
> requirements to combine JIT and GDB. It allows these emiiters to be  
> efficient and be inlined functions. If you study the code you will  
> see what I mean.

What's the state of the current ObjectCodeEmitter? Are we planning to  
de-templatize X86CodeEmitter, etc?

Evan

>
> Aaron
>