<div>Reid,</div>
<div> </div>
<div>Sorry it was the right patch, yes your option #2 looks like the best solution. We are probably going to have to revert back to the old MachineCodeEmitter class as for some reason Chris and Evan don't like templates in the CodeEmitter's. So we will probably be employing the same extend method and relocations as with the JITCodeEmitter patch I forwarded earlier.</div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>Aaron<br><br></div>
<div class="gmail_quote">2009/7/8 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>Ah Reid,</div>
<div> </div>
<div>I sent out the wrong patch in panick over the templating bussiness. The actual patch has extra emit methods after the extend() method calls that allow the exection to continue after the JITCodeEmitter's parent has changed the buffer for an extended one.</div>
<div> </div>
<div>Aaron<br><br></div>
<div class="gmail_quote">2009/7/7 Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@mit.edu" target="_blank">rnk@mit.edu</a>></span>
<div>
<div></div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>On Tue, Jul 7, 2009 at 8:27 AM, Aaron<br>Gray<<a href="mailto:aaronngray.lists@googlemail.com" target="_blank">aaronngray.lists@googlemail.com</a>> wrote:<br>> It also has a extend() method for extending the buffer and continuing if th<br>
> buffer overfolws. And a reserveBytes that can be used in conjunction with<br>> the raw*emit methods to allow a whole instruction to be output without any<br>> buffer checking.<br><br></div>Are you planning to change the JITEmitter to JITMemoryManager API with<br>
this extend method? From what I can tell this just moves the FIXME<br>around.<br><br>There are two ways I can see the JITEmitter working:<br><br>1) The current API where the target-specific CodeEmitters wrap<br>emission in a do { startFunction(F); ... } while (finishFunction(F));<br>
loop. When finishFunction fails and returns true, the memory manager<br>needs to try again with more memory next time. This is what I've been<br>working on. I've fixed up the emitter so that it will request more<br>
memory, and the memory manager so that it will actually allocate more<br>blocks of memory when it runs out.<br><br>2) A nicer API where we emit code into a buffer, say a raw_ostream or<br>vector<char>, figure out how big it is, allocate exactly that much<br>
memory, and then run the relocations over it *after* it has been<br>emitted. The trick here is that you don't actually know the function<br>start address until after you've emitted the code, and I don't know<br>
how much that complicates code generation. If we can take care of<br>that with relocations, then I see no reason to use the more complex<br>API #1. However, there could be other reasons why people chose API #1<br>back in the day that I'm not aware of.<br>
<br>I'm just wondering what the plan is.<br><br>Reid<br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br></blockquote></div></div></div><br></blockquote></div><br>