llvm dev - Jul 2009 - [LLVMdev] [patch] CodeEmitter Memory Foot Reduction

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.

-Chris

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
classes.

class MachineCodeEmitter {
public:
  ....
  inline void emitByte( uint8_t b) {
    if (freespace())
      BufferPtr++ = b;
    else {
      extend();
       BufferPtr++ = b;
    }
  }

protected:
  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.

Aaron


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

2009/7/16 Aaron Gray <aaronngray.lists at googlemail.com>
>  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
> classes.
>
> class MachineCodeEmitter {
> public:
>   ....
>   inline void emitByte( uint8_t b) {
>     if (freespace())
>       BufferPtr++ = b;
>     else {
>       extend();
>        BufferPtr++ = b;
>     }
>   }
>
> protected:
>   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.
>
Oh, and JITEmitter::finishFunction will have to provide relocations for JIT
too.

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