<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">OK - I have a new patch for review, which incorporates Andrew's feedback.<div><br><div>The patch exposes the MCJIT via the C API.</div><div><br></div><div>The current API uses the SectionMemoryManager by default. I plan to expose the ability to have the C API call back into the client's code, and use the client's own memory manager, in the future. But even then, the default will be SectionMemoryManager. Because this requires calling applyPermissions(), I also expose the ExecutionEngine::finalizeObject() method. This was tricky - I take it that in the future, this method will take a Module*M parameter to specify which module to finalize. In order to not create future confusion in the C API, I expose this as LLVMFinalizeAllObjects() and specify the API's semantics as being that all objects associated with the execution engine should be finalized.</div><div><br></div><div>The patch also exposes the NoFramePointerElim option. The manner in which options are exposed is designed for forward compatibility; you supply an options struct along with a size which you zero-fill prior to manipulating. This is similar to the idiom I've seen used in other C APIs like BerkeleyDB. I considered having separate C function calls for each option, in the style of the ExecutionEngineBuilder API - but while that idiom feels right to me in C++, it feels less C-like. As well, the current options approach exposes not just parts of the Builder but also part of TargetOptions (namely, NoFramePointerElim). It's also more concise in practice.</div><div><br></div><div>I plan to expose more innards through the LLVMMCJITCompilerOptions in the future. I'd be happy to do more of that in one go if that was preferred; but I thought that a baby step would be the best thing for now.</div><div><br></div><div></div></div></body></html>