<div class="gmail_quote">Sorry, I reply to group too...</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">2009/7/16 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.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="im">On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Chris,<br><br>If you/we do not like this code, then the alternatives are :-<br>1) Leave as is, which I would not suggest.<br>
2) Revert to using MachineCodeEmitter like mechanics with virtual extend() method to allow rebuffering with ObjectCodeEmitter providing the memory management.<br>3) Don't really know of any other alternatives :)<br><br>
2 maybe the best compromise option. Its easy to code, removes templating from the CodeEmitters, and is virtually transparent to our other DOE work. The only thing it does not write via a BinaryObject object, so we loose that functionality.<br>
</blockquote><br></div>Hi Aaron,<br><br>I'm sorry for not getting back to you sooner. I work fairly LIFO and the craziness that has happened since your emails have distracted me.</blockquote>
<div> </div>
<div>Okay.</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>One problem with this patch is that (for example) X86TargetMachine.cpp refers to the "createX86ObjectCodeEmitterPass" symbol, which forces the code emitter to object code emitter to be linked into the X86 target module. There is still no way to create a JIT without two copies of the code emitter template.</blockquote>
<div> </div>
<div>I see, I have missed that :(</div>
<div> </div>
<div>>I believe that aligning this work with Daniels work to make the targets more modular would >be straight forward. Are you willing to do this?</div>
<div> </div>
<div>Whats Daniels approach, does he have any online documentation or code, do you have an email address so I may talk to him.</div>
<div><br>>This patch keeps around the templates, which I really don't like. However, this is better >than what is in mainline, so it seems like a reasonable step to me if you really really want >to do this. </div>
<div> </div>
<div>No if it does not work without having to go thurther and mess with TargetMachine's then its not solved what it is set out to solve.</div>
<div> </div>
<div>I did some 'stats' for if it had worked :-</div>
<div> </div>
<div><a href="mailto:pre-doe@72630">pre-doe@72630</a><br> AlphaCodeEmitter.o 23,155 Bytes<br> ARMCodeEmitter.o 71,125 Bytes<br> PPCCodeEmitter.o 31,629 Bytes<br> X86CodeEmitter.o 39,313 Bytes<br>
<a href="mailto:doe@72631">doe@72631</a><br> AlphaCodeEmitter.o 32,642 Bytes<br> ARMCodeEmitter.o 158,219 Bytes<br> PPCCodeEmitter.o 42,380 Bytes<br> X86CodeEmitter.o 81,491 Bytes<br>
<a href="mailto:doe@72631+opt">doe@72631+opt</a><br> AlphaCodeEmitter.o 14,300 bytes<br> AlphaJITCodeEmitter.o 9,103 bytes<br> AlphaMachineCodeEmitter.o 9,216 bytes</div>
<div> </div>
<div> ARMCodeEmitter.o 2,499 bytes<br> ARMJITCodeEmitter.o 88,454 bytes<br> ARMMachineCodeEmitter.o 89,499 bytes<br> <br> PPCCodeEmitter.o 17,896 bytes<br> PPCJITCodeEmitter.o 14,239 bytes<br>
PPCMachineCodeEmitter.o 14,364 bytes</div>
<div> </div>
<div> X86CodeEmitter.o 46,909 bytes<br> X86JITCodeEmitter.o 46,858 bytes<br></div>
<div> </div>
<div>>However, I still don't understand why you're unwilling to make the CodeEmitter >be a virtual >base class instead of a template!</div>
<div> </div>
<div>The basic idea of using templates inconjunction with inlining is for efficiency. <br> <br>6,500 virtual calls outputting bytes out of 10000 calls, and the rest 1,750 being words to output 10KBytes of code does not entice me to use virtual calls.</div>
<div> </div>
<div>Aaron</div>
<div> </div></div>