[LLVMdev] [patch] CodeEmitter Memory Foot Reduction

Aaron Gray aaronngray.lists at googlemail.com
Thu Jul 16 11:55:03 PDT 2009

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

> On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote:
>> I understand that you say that, but I can't bring myself to care at this
>> point.  Have you thought about how many cycles are already used to produce
>> the instructions that lead to the emission of those 10K bytes?  The total
>> percentage of time spent doing these virtual calls will be tiny compared to
>> the total time to generate the code.
>> If you switch to using virtual functions, get the code working, and we
>> *measure* a performance problem, then we can fix it.  There are much better
>> ways to do this than templating the whole code emitter.
>> That means JIT code also has the virtual function overhead too, this will
>> slow down existing JIT code. Templates are already there and they work and
>> they do not take up _too_ much memory.
> As I said before, if you are compelled to, feel free to continue with your
> approach of premature optimization.  I will fix it later.

If you are not too bothered with the memory overhead in the short term then
it is probably best to leave the code as it is for meantime.

I think the original MachineCodeEmitter with inline emit* functions and for
virtual functions like extend() so we can control memory management in sub

class MachineCodeEmitter {
  inline void emitByte( uint8_t b) {
    if (freespace())
      BufferPtr++ = b;
    else {
       BufferPtr++ = b;

  void virtual extend() = 0

so extend is overriden in JITCodeEmitter and ObjectCodeEmitter and is
called moving emitted code to a bigger buffer if we run out of memory, then
emission continues.

This gives the lowest overhead and flexability. If ObjectCodeEmitter and
JITEmitter manage memory then the design is transparent to the higher levels
of DOE and JIT.

The old design was the best design it just needed an extend() method.


> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090716/e83b246b/attachment.html>

More information about the llvm-dev mailing list