[PATCH] MCJIT::clearSymbolAddress

[Kaylor, Andrew]

Your smart function replacement strategy could work.  It would still leave a small problem if the replaced function is called from within its own module, but perhaps we could just document that limitation.

You're right that this will be important for replacing the old JIT.

Let me think about the API a bit and we can get something in place for this.  If the API is good then we can put a partial solution in place and just document the need for further refinements in the implementation.

Thanks,
Andy


From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Friday, October 18, 2013 11:48 AM
To: Kaylor, Andrew
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] MCJIT::clearSymbolAddress

Hi Andy,

Everything you write is correct. This is not enough. It's part of the API required a complete solution.

If function replacement is not possible for a compiled module, given this API and a relink function, a solution could be a smart function replacer:

If the function signature is the same, the usual case, hide/replace the old function, recompile it and relink all callers to the new function.

If the function signature changed, hide/replace/recompile the function and its callers (possibly in a new module hiding the old copies) and relink the callers-callers to the new callers.

This does leak memory of the hidden compiled functions we're replacing.

If we can mange this I think that the transition from the old JIT would be much easier.

Yaron



2013/10/18 Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
This is a potentially tricky case.  Let me give you a hypothetical scenario:

Module A contains a function FA.
Modules B and C contain functions (FB and FC) that call FA.
Module D contains a new definition of FA.

Now suppose I add modules A, B and C to MCJIT and make a call to FB.  This will generate code for modules A and B and link module B to module A's definition of FA.  Then suppose I call your new function to clear the FA symbol and add module D to MCJIT.  Now if I call FC, MCJIT will generate code for modules C and D and link FC to module D's definition of FA.  However, module B will still be linked to module A's definition of FA.

To complicate things even further, if there were some unrelated function in module B that required another unrelated function in module C then FC will be bound to module A's FA when FB is called, though that might not be obvious to the user.  Even worse, if FC calls FB and FA then it would be possible to have FC linked to module A's FA through FB and to module D's FA through its direct call.

That's not to say that we don't need to address your use case.  I just don't think the simple solution is enough.

-Andy

From: Yaron Keren [mailto:yaron.keren at gmail.com<mailto:yaron.keren at gmail.com>]
Sent: Friday, October 18, 2013 4:39 AM
To: llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>; Kaylor, Andrew
Subject: [PATCH] MCJIT::clearSymbolAddress

The use-case is replacing a named function before creating a same-named function in a new module, such as in REPL.

With the older JIT a function could be removed from the symbol table (and memory freed) by calling freeMachineCodeForFunction.

The new MCJIT does not implement this function - may be impossible to modify the object - so the next best thing is to remove the symbol from the symbol table so the older copy will not be found anymore and then a new function could be created.

Since MCJIT uses GlobalSymbolTable in RuntimeDyldImpl.h rather than the GlobalAddressMap in ExecutionEngineState (could EEState be reused by MCJIT somehow?) the code is MCJIT specific.

To expose it to the programmer the function appears in EE as well with a comment and the call chain is

EE->MCJIT->RuntimeDyld->RuntimeDyldImpl->GlobalSymbolTable.erase().

Yaron


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131018/249b4418/attachment.html>