[llvm] r191030 - llvm-c: Add LLVMGetPointerToFunction

[Kaylor, Andrew]

I've been working on the MCJIT interface today.  There are a lot of ugly things there as a result of sharing a base class with the old JIT engine.

With regard to the getPointerToX functions, I was thing about adding new methods getXAddress that return uint64_t values and calling the old ones deprecated.  I'm not sure that helps with the C API, but I thought I'd mention it.

Is there any reason not to have this function return a uint64_t?  Even the void pointer would need to be cast to something else to be useful.

BTW, the current implementation of MCJIT::runFunction() will definitely not work if the target is remote.

-Andy

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Jim Grosbach
Sent: Thursday, September 19, 2013 2:27 PM
To: Filip Pizlo
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm] r191030 - llvm-c: Add LLVMGetPointerToFunction


On Sep 19, 2013, at 2:04 PM, Filip Pizlo <fpizlo at apple.com<mailto:fpizlo at apple.com>> wrote:



On Sep 19, 2013, at 1:49 PM, Jim Grosbach <grosbach at apple.com<mailto:grosbach at apple.com>> wrote:



On Sep 19, 2013, at 1:46 PM, Filip Pizlo <fpizlo at apple.com<mailto:fpizlo at apple.com>> wrote:


How is that different from LLVMGetPointerToGlobal()?

It's not. That's broken, too.


And I agree that this should work.  It's great that the JIT could be used for remote execution, but some clients will never use the JIT in that fashion.  They will just want a void*.

Then they will use a memory manager that can make additional guarantees such as the opaque uint64_t value is actual just a bitcasted local pointer which can be safely cast back to void* or whatever. That's a client-process usage, however, and not a guarantee of the JIT API.

Are you saying that if a LLVM C API client doesn't install a custom memory manager, then the MCJIT is semantically permitted to JIT the code into a remote process?

No, I'm saying the API has to be semantically rich enough to be agnostic about remote vs. local. That's a function of the memory manager interface. The default memory manager does indeed to local currently. I have mixed feelings about making that an explicit guarantee.


Currently the C API has no facility for asking for code to be JITed into something remote, and it seems like it would be a bug if the JIT did this without the client asking for it.  It makes far more sense to me that the C API continues to have a hard constraint that JITing is local, and that the end result is a function that lives in your address space.

I strongly disagree. The C API is about exposing functionality, not imposing additional constraints.


-Jim




On Sep 19, 2013, at 1:36 PM, Eric Christopher <echristo at gmail.com<mailto:echristo at gmail.com>> wrote:


Hrm. That's a good point and one I hadn't thought about... what's the
best way forward here? There's definitely a useful need in getting a
void * to a function out of the JIT from the C level.

-eric

On Thu, Sep 19, 2013 at 1:30 PM, Jim Grosbach <grosbach at apple.com<mailto:grosbach at apple.com>> wrote:

This isn't going to work when the execution target isn't local. The pointer to the function is in the executing process address space and this returns a pointer in the compiler's address space.

That's a fundamental problem with the old JIT, and is semi-baked into the ExecutionEngine API, unfortunately, and cleaning that up is going to be painful. We shouldn't, however, make the problem worse.

-Jim

On Sep 19, 2013, at 12:55 PM, Anders Waldenborg <anders at 0x63.nu<mailto:anders at 0x63.nu>> wrote:


Author: andersg
Date: Thu Sep 19 14:55:06 2013
New Revision: 191030

URL: http://llvm.org/viewvc/llvm-project?rev=191030&view=rev
Log:
llvm-c: Add LLVMGetPointerToFunction

Differential Revision: http://llvm-reviews.chandlerc.com/D1715


Modified:
  llvm/trunk/include/llvm-c/ExecutionEngine.h
  llvm/trunk/lib/ExecutionEngine/ExecutionEngineBindings.cpp

Modified: llvm/trunk/include/llvm-c/ExecutionEngine.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/ExecutionEngine.h?rev=191030&r1=191029&r2=191030&view=diff
==============================================================================
--- llvm/trunk/include/llvm-c/ExecutionEngine.h (original)
+++ llvm/trunk/include/llvm-c/ExecutionEngine.h Thu Sep 19 14:55:06 2013
@@ -141,6 +141,8 @@ LLVMGenericValueRef LLVMRunFunction(LLVM
                                   unsigned NumArgs,
                                   LLVMGenericValueRef *Args);

+void *LLVMGetPointerToFunction(LLVMExecutionEngineRef EE, LLVMValueRef F);
+
void LLVMFreeMachineCodeForFunction(LLVMExecutionEngineRef EE, LLVMValueRef F);

void LLVMAddModule(LLVMExecutionEngineRef EE, LLVMModuleRef M);

Modified: llvm/trunk/lib/ExecutionEngine/ExecutionEngineBindings.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/ExecutionEngineBindings.cpp?rev=191030&r1=191029&r2=191030&view=diff
==============================================================================
--- llvm/trunk/lib/ExecutionEngine/ExecutionEngineBindings.cpp (original)
+++ llvm/trunk/lib/ExecutionEngine/ExecutionEngineBindings.cpp Thu Sep 19 14:55:06 2013
@@ -276,6 +276,10 @@ LLVMGenericValueRef LLVMRunFunction(LLVM
 return wrap(Result);
}

+void *LLVMGetPointerToFunction(LLVMExecutionEngineRef EE, LLVMValueRef F) {
+  return unwrap(EE)->getPointerToFunction(unwrap<Function>(F));
+}
+
void LLVMFreeMachineCodeForFunction(LLVMExecutionEngineRef EE, LLVMValueRef F) {
 unwrap(EE)->freeMachineCodeForFunction(unwrap<Function>(F));
}


_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130920/4f7a7191/attachment.html>