[llvm-commits] [patch] JITCodeEmitter speedup patch

[Aaron Gray]

Reid,

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.

Thanks,

Aaron

2009/7/8 Aaron Gray <aaronngray.lists at googlemail.com>

> Ah Reid,
>
> 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.
>
> Aaron
>
> 2009/7/7 Reid Kleckner <rnk at mit.edu>
>
>  On Tue, Jul 7, 2009 at 8:27 AM, Aaron
>> Gray<aaronngray.lists at googlemail.com> wrote:
>> > It also has a extend() method for extending the buffer and continuing if
>> th
>> > buffer overfolws. And a reserveBytes that can be used in conjunction
>> with
>> > the raw*emit methods to allow a whole instruction to be output without
>> any
>> > buffer checking.
>>
>> Are you planning to change the JITEmitter to JITMemoryManager API with
>> this extend method?  From what I can tell this just moves the FIXME
>> around.
>>
>> There are two ways I can see the JITEmitter working:
>>
>> 1) The current API where the target-specific CodeEmitters wrap
>> emission in a do { startFunction(F); ... } while (finishFunction(F));
>> loop.  When finishFunction fails and returns true, the memory manager
>> needs to try again with more memory next time.  This is what I've been
>> working on.   I've fixed up the emitter so that it will request more
>> memory, and the memory manager so that it will actually allocate more
>> blocks of memory when it runs out.
>>
>> 2) A nicer API where we emit code into a buffer, say a raw_ostream or
>> vector<char>, figure out how big it is, allocate exactly that much
>> memory, and then run the relocations over it *after* it has been
>> emitted.  The trick here is that you don't actually know the function
>> start address until after you've emitted the code, and I don't know
>> how much that complicates code generation.  If we can take care of
>> that with relocations, then I see no reason to use the more complex
>> API #1.  However, there could be other reasons why people chose API #1
>> back in the day that I'm not aware of.
>>
>> I'm just wondering what the plan is.
>>
>> Reid
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090708/ea1b74e4/attachment.html>