<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">rnk@mit.edu</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 Tue, Jul 7, 2009 at 8:27 AM, Aaron<br>Gray<<a href="mailto:aaronngray.lists@googlemail.com">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">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><br>