reid.kleckner at gmail.com
Tue Jul 20 10:06:53 PDT 2010
Some boring style comments:
- whack trailing whitespace
- spaces, not tabs
- the methods in MCJITStreamer.cpp should probably have blank lines between them
There seems to be an ownership problem of the MCJITObjectWriter. If I
understand the code correctly, the assembler Finish method takes
ownership of the Writer parameter, which presumably is needed to JIT
+1 for separate patches, or alternatively, can we just commit this and
begin developing this in-tree? Then other people can hack on it
before it's considered "ready". :)
There's also a lot of copying stuff out of the JIT going on. The
MCJIT doesn't need to reimplement things like the JITEventListener
interface, for example. I think you should either:
- Maybe make a svn branch and replace the JIT in-place.
- Try to reuse the support classes whenever possible.
Regarding the memory management strategy, I'd like to take this
opportunity to try to do something more sane than the current JIT.
Instead of streaming the code directly into RWX memory, it would be
better to stream to some other resizeable in-memory data structure,
and allocate the RWX memory once the size is known. You can probably
wait on this one, but I'd like to see this eventually.
On Mon, Jul 19, 2010 at 5:14 AM, Olivier Meurant
<meurant.olivier at gmail.com> wrote:
> Together with Jan Sjodin (in copy of this email), we begin an
> implementation of the JIT with MC. The idea, suggested by Jan, is to
> develop a MCJIT in parallel of the current JIT and to keep the two
> implementations until (at least) the new MC one is mature enough.
> Currently code is kept on gitorious
> Following this, a boolean "bool MCJIT = false" has been introduced to
> the "static ExecutionEngine *create(...)" method, allowing the lli
> tool to use the MCJIT with the optional flag "-mcjit".
> The MCJIT can now execute little functions with no relocation (like
> add(a,b) => a+b), to do that some modifications have been made :
> - The addPassesToEmitMC method has been added to TargetMachine class.
> It fills the MCContext pointer so we can build the MCJITStreamer.
> - The Finish method of MCAssembler have a new optional argument
> "Writer" to allow a custom MCJITObjectWriter to be used.
> Can you give us some feedbacks on the general idea and on this 2
> particular hooks ?
> Currently MCJIT has one unittest and the binary size is quite big
> (~110MB in debug...) because before using the MC framework we need to
> call "InitializeAllTargets()" and friends (same as llc does). For the
> JIT, we need only the "host" backend and "InitializeHostTarget()"-like
> method doesn't seem to exist. Do you have an opinion on this ?
> Attached you will find the patch introducing the first MCJIT draft.
> Can you comment on this ?
> Jan and Olivier.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev