[LLVMdev] linking individual functions in execution module

Kaylor, Andrew andrew.kaylor at intel.com
Mon Nov 26 12:27:14 PST 2012


What I was thinking is that if you need to link to module A to functions in module B (which you know might be re-JITed) you can have a stub function that gets used as the address called by module A and then you can use some brute force approach to maintain the actual address of the function in module B as it is re-JITed (maybe the stub could be a lightweight class with a member variable that's kept up-to-date or whatever).  The problem I'm trying to solve with this approach is that once you return the address of a function from the memory manager's getPointerToNamed function, the address you return is going to be written into the JITed code as part of the linking process, so you need a central location to maintain updates to that address.

Your approach of linking with a cloned copy of the module (before JITing?) would work too.  The main downside I see to that is you may end up JITing multiple copies of functions in the cloned module.  That may be OK.  Something very similar was done in a project I worked on here at Intel and the results were good.

Obviously it's your call as far as weighing the overhead of duplicated modules versus the overhead of maintaining stubs.  In a lot of circumstances the cloning approach would be better.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of charles quarra
Sent: Thursday, November 22, 2012 7:32 AM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] linking individual functions in execution module

2012/11/21 Kaylor, Andrew <andrew.kaylor at intel.com>:

> If you re-JIT a module that you have previously linked to that will obviously cause some problems, but you can probably work around that with a stub function.

could you elaborate a little bit on that ? i was thinking in something different; linking a cloned copy of the module rather than the module directly. Would that work better than this approach?


thanks
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list