[llvm] r191030 - llvm-c: Add LLVMGetPointerToFunction

[Kaylor, Andrew]

> That's a really good idea. For the C API, we just expose those instead. We should put a
> bit of thought into the inputs there, though.  The current interfaces use pointers from 
> the IR (Value* and such), but that's not long term viable, as there's nothing in the MCJIT
> which requires that the lifetime of the Module be >= the lifetime of the resultant compiled 
> code. I'd much rather the interfaces be via name, but that has other complications
> (platform specific name mangling, etc..).

Yeah, I was thinking about that yesterday too, particularly as it relates to the problem of memory consumption.  Right now RuntimeDyld and MCJIT are both holding on to a whole lot of things that they don't need, but when you start trying to decide what they can get rid of it tends toward everything but the final loaded code, which is owned by the memory manager anyway.

Of course, we need to keep something to figure out where the symbols are unless we want the lookup to be really slow.

The current implementation of getPointerToFunction actually does the look up by name, so putting that in the API wouldn't give us any more problems than we already have.  However, as I'm adding multiple module support, the IR objects are handy for figuring out which Module we expect to have had the thing we're looking for and deciding whether or not we need to generate code for it.  Obviously there are ways to solve that.

Then there's the odd getPointerToNamedFunction which for some reason doesn't want to look at functions in the code the MCJIT has emitted.  I don't understand why that's there.

-Andy