[llvm-commits] [patch] JITCodeEmitter speedup patch

[Reid Kleckner]

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