[LLVMdev] Fwd: Re: Fwd: updating module references in call instructions after a module clone

John Criswell criswell at illinois.edu
Thu Dec 6 09:49:07 PST 2012

Forgot to CC the list.

-- John t.

-------- Original Message --------
Subject: 	Re: [LLVMdev] Fwd: updating module references in call 
instructions after a module clone
Date: 	Thu, 06 Dec 2012 11:48:37 -0600
From: 	John Criswell <criswell at illinois.edu>
Organization: 	University of Illinois
To: 	charles quarra <charllsnotieneningunputocorreo at gmail.com>

On 12/6/12 11:43 AM, charles quarra wrote:
> (i hope bumping my own question as a way for begging attention is not
> too frowned upon on the list, otherwise i can adjust the frequency as
> low as required)
> suppose module B has call/InvokeInst to calls in module A
> after i clone both modules i get B' and A'
> my concrete question is this:
> Are there any special steps that i need to do before linking the
> modules B' and A' together?

If I understand correctly, you have a function in module A (call it
foo), and you're calling it from module B (so B declares foo as an
externally defined function).  Is this correct?

If so, if you clone B and A, and the cloning doesn't change the names of
the functions, and you link the clones but not the originals, then I
would think it would just link together.

-- John T.

> my main concern is that B' will have call/InvokeInst pointing to
> module A, not A', and the linker will not be able to notice that it
> should replace A' references with A
> The reason for linking B' and A' instead of A and B is to avoid
> rebuilding all modules when only a few of them change
> any suggestions about this are greatly welcome
> _______________________________________________
> 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/20121206/c716b247/attachment.html>

More information about the llvm-dev mailing list