<div class="gmail_quote">2009/7/16 Aaron Gray <span dir="ltr"><<a href="mailto:aaronngray.lists@googlemail.com">aaronngray.lists@googlemail.com</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="gmail_quote">
<div class="im">2009/7/16 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span><br></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div><br>
<div>
<div></div>
<div class="h5">On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote:<br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>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.<br>

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

</blockquote><br></div></div></div>
<div>
<div></div>
<div class="h5">As I said before, if you are compelled to, feel free to continue with your approach of premature optimization.  I will fix it later.</div></div></blockquote>
<div> </div>
<div>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.</div>
<div> </div>
<div>I think the original MachineCodeEmitter with inline emit* functions and for virtual functions like extend() so we can control memory management in sub classes.</div>
<div> </div>
<div>class MachineCodeEmitter {</div>
<div>public:</div>
<div>  ....</div>
<div>  inline void emitByte( uint8_t b) {</div>
<div>    if (freespace())</div>
<div>      BufferPtr++ = b;</div>
<div>    else {</div>
<div>      extend();</div>
<div>
<div>      BufferPtr++ = b;</div>    }</div>
<div>  }</div>
<div> </div>
<div>protected:</div>
<div>  void virtual extend() = 0</div>
<div>};</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>The old design was the best design it just needed an extend() method.</div></div></blockquote>
<div> </div>
<div>Oh, and JITEmitter::finishFunction will have to provide relocations for JIT too.</div>
<div> </div>
<div>Aaron</div>
<div> </div></div>