[LLVMdev] [patch] CodeEmitter Memory Foot Reduction

[Aaron Gray]

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>