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

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>

There's probably a lot that we could do, but I can't think of anything
easy.

Basically every time we need to look up a symbol by name we're going to each
module and saying "Do you have this symbol?"  It would likely be much
better if we grabbed the function names from the module and did the search
ourselves so that we could keep some information about the things that
didn't match and optimize the next search.

-Andy

From: Jim Grosbach [mailto:grosbach at apple.com]
Sent: Monday, October 21, 2013 4:39 PM
To: Kaylor, Andrew; Yaron Keren
Cc: <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress

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<mailto: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<mailto: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<mailto: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/f5185717/attachment.html>

I don’t follow. Why are we looking at the module at all? That query should work
even (especially) after the Module is deleted. We should be able to have a local
symbol table that’s a DenseMap or something similar to resolve from names to
target addresses. That map would be updated as part of the compilation when the
object’s symbol table gets read.

-Jim

On Oct 21, 2013, at 4:55 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:
> There’s probably a lot that we could do, but I can’t think of anything
easy.
>  
> Basically every time we need to look up a symbol by name we’re going to
each module and saying “Do you have this symbol?”  It would likely be much
better if we grabbed the function names from the module and did the search
ourselves so that we could keep some information about the things that didn’t
match and optimize the next search.
>  
> -Andy
>  
> From: Jim Grosbach [mailto:grosbach at apple.com] 
> Sent: Monday, October 21, 2013 4:39 PM
> To: Kaylor, Andrew; Yaron Keren
> Cc: <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress
>  
> 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/099dcbd4/attachment.html>