[PATCH] SectionMemoryManager is not a JITMemoryManager

[Filip Pizlo]

This patch cleans up the relationship between RTDyldMemoryManager, JITMemoryManager, and EngineBuilder.

As I understand it, JITMemoryManager is meant to go away at some point, and RTDyldMemoryManager is not meant to be predestined to have to support all of the things that JITMemoryManager had; it may have some of the same things, but also maybe some new things, and probably not all of the old things.

But right now EngineBuilder doesn't know anything about RTDyldMemoryManager and assumes that JITMemoryManager is the way memory is managed in both MCJIT and the old JIT.  This means that if you want to pass an RTDyldMemoryManager to the MCJIT via the EngineBuilder API, you have to actually create a JITMemoryManager and stub out a *bunch* of methods.  SectionMemoryManager does this, for example: SectionMemoryManager is a subtype of JITMemoryManager that cannot actually be used as a JITMemoryManager, except passing it through EngineBuilder so that MCJIT can use it as an RTDyldMemoryManager. :-/

This patch attempts to fix the problem:

- EngineBuilder now knows that RTDyldMemoryManager and JITMemoryManager are different but similar things.  It knows that if you set a JITMemoryManager, then it can be used for the MCJIT.  It knows that an RTDyldMemoryManager can also be used for the MCJIT, but cannot be used for old JIT.  It will ensure that you cannot set both at the same time since that would be confusing (setting one overrides the other).

- SectionMemoryManager is no longer a subtype of JITMemoryManager, and no longer has a ton of stub unimplemented methods.

- lli and various tests are changed to know that a SectionMemoryManager is not a JITMemoryManager.

This is a change to the C++ API, and I actually don't know that the policies on this are!  But I hope that this is something that we can change, since it kills some gnarly code and concentrates whatever little ugliness remains into EngineBuilder (it's only ugly because it has to know that there are two kinds of ways of saying that you want to manager memory yourself).

-Filip

-------------- next part --------------
A non-text attachment was scrubbed...
Name: secmm.patch
Type: application/octet-stream
Size: 12633 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130504/5769b3ff/attachment.obj>