llvm dev - Oct 2013 - [LLVMdev] An enhancement for MCJIT::getFunctionAddress

In MCJIT, the old JIT functions are deprecated in favor
of getFunctionAddress.
Code like:

  llvm::Function *F = M->getFunction(FuncName);
  void *FN = EE->getPointerToFunction(F);

should be rewritten as

  uint64_t FN = EE->getFunctionAddress(FuncName);

While functionally identical, in case the correct module is known the new
version will be much slower, linear with the number of added (but not
loaded) modules, since it has to (possibly) search for the correct module
while old code directly searches the correct module.

To solve the issue, getFunctionAddress could get an optional Module
"hint"
(=NULL by default) which - if provided - will make getSymbolAddress skip
calling findModuleForSymbol (a very slow operation) and instead directly
use the Module provided.

Yaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131020/04318b9d/attachment.html>

I should have read this before sending my previous reply. :-)

I'm not a big fan of default parameters, but some form of what you are
suggesting may be useful.  See my other comments on this topic in the other
reply.

-Andy


From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Saturday, October 19, 2013 3:17 PM
To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu>
Subject: An enhancement for MCJIT::getFunctionAddress

In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress.
Code like:

  llvm::Function *F = M->getFunction(FuncName);
  void *FN = EE->getPointerToFunction(F);

should be rewritten as

  uint64_t FN = EE->getFunctionAddress(FuncName);

While functionally identical, in case the correct module is known the new
version will be much slower, linear with the number of added (but not loaded)
modules, since it has to (possibly) search for the correct module while old code
directly searches the correct module.

To solve the issue, getFunctionAddress could get an optional Module
"hint" (=NULL by default) which - if provided - will make
getSymbolAddress skip calling findModuleForSymbol (a very slow operation) and
instead directly use the Module provided.

Yaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/c12049fe/attachment.html>

The search is linear? If that’s really true, we should fix that.

On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:
> I should have read this before sending my previous reply. :-)
>  
> I’m not a big fan of default parameters, but some form of what you are
suggesting may be useful.  See my other comments on this topic in the other
reply.
>  
> -Andy
>  
>  
> From: Yaron Keren [mailto:yaron.keren at gmail.com] 
> Sent: Saturday, October 19, 2013 3:17 PM
> To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu>
> Subject: An enhancement for MCJIT::getFunctionAddress
>  
> In MCJIT, the old JIT functions are deprecated in favor of
getFunctionAddress.
> Code like:
>  
>   llvm::Function *F = M->getFunction(FuncName);
>   void *FN = EE->getPointerToFunction(F);
>  
> should be rewritten as
>  
>   uint64_t FN = EE->getFunctionAddress(FuncName);
>  
> While functionally identical, in case the correct module is known the new
version will be much slower, linear with the number of added (but not loaded)
modules, since it has to (possibly) search for the correct module while old code
directly searches the correct module.
>  
> To solve the issue, getFunctionAddress could get an optional Module
"hint" (=NULL by default) which - if provided - will make
getSymbolAddress skip calling findModuleForSymbol (a very slow operation) and
instead directly use the Module provided.
>  
> Yaron
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/2cbecc4a/attachment.html>