[llvm-dev] Replacing a function from one module into another one
Daniel Moya via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 4 04:18:19 PDT 2018
Hi Philip,
Thank you very much for your answer, the vector declaration example worked.
I'm pretty sure the ValueToValueMapTy is the last thing I need because I
even saw there is another function that could help me llvm*:*:RemapFunction
<http://llvm.org/doxygen/namespacellvm.html#addf0183e92893bdbcde00fc9091dda93>;
but my problem is that I don't know how to populate the ValueToValueMapTy
(VMap) and I couldn't find a single complete example on the internet. To
begin with, as the name implies (and also from some errors that I got) the
ValueToValueMapTy takes a std::pair<llvm::Value, llvm::Value>, but what I
need is to map the arguments (llvm::Attribute) of both functions (the first
argument of foo2 is equivalent to the first argument of foo3, and so on),
however, apparently there's no transformation from a llvm::Attribute to a
llvm::Value. I'm using the function getAttribute
<http://llvm.org/doxygen/classllvm_1_1Function.html#ab2a5fc8baaee7e74dbe47d848508745a>
(unsigned <http://llvm.org/doxygen/classunsigned.html> i, StringRef
<http://llvm.org/doxygen/classllvm_1_1StringRef.html> Kind
<http://llvm.org/doxygen/ARMAsmParser_8cpp.html#a5ec5335889cd241b0ccfd4e4e58cf52e>
) const
<http://llvm.org/doxygen/AArch64PromoteConstant_8cpp.html#a90f8350fecae261c25be85d38b451bff>
to
get the attributes, but I don't even understand why is it required to give
the StringRef <http://llvm.org/doxygen/classllvm_1_1StringRef.html> Kind
<http://llvm.org/doxygen/ARMAsmParser_8cpp.html#a5ec5335889cd241b0ccfd4e4e58cf52e>
if
what I need is just the attribute of the function in the *i *position. I'm
really thankful for the quick responses and for the attention received.
Regards,
Daniel Moya
El lun., 3 de sep. de 2018 a la(s) 18:42, Philip Pfaffe (
philip.pfaffe at gmail.com) escribió:
> Hi Daniel,
>
> CloneFunctionInto wants to tell you about the new ReturnInstructions it
> produced, you're expected to pass a vector for this purpose. You're free to
> ignore these values, though, but you still have to pass that
> vector: SmallVector<ReturnInst*, 8> Returns;
>
> For the argument remapping, you're supposed to pre-populate the VMap you
> pass with the appropriate argument-to-argument mapping.
>
> It's perfectly fine to use CloneFunctionInto across modules, btw. Only
> operations across LLVMContexts are tricky.
>
> Cheers,
> Philip
>
> On Mon, Sep 3, 2018 at 6:31 PM Daniel Moya via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Thank you Ahmad,
>>
>> I figured out that, although the type of both p(oInst) and p(nInst) were
>> the same, I had to:
>>
>> for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) {
>> callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType());
>> }
>>
>> that solves the issue at the calling instruction in the main function,
>> but now I see that *linkModules* does not work for me (it's a mess to
>> bring all the other unnecessary functions from the reference module) so
>> what I need is to directly move one function from one module to another
>> one. I'm still facing the issue with the *llvm::SmallVectorImpl<
>> llvm::ReturnInst *> &Returns *argument for the *CloneFunctionInto, *can
>> anyone please give an example of use of that function? I guess that's the
>> only way because otherwise if I move the blocks from foo3 in the refModule
>> to the oldModule, the references of the moved block still point to the
>> arguments of foo3 defined in the refModule, and I don't know how to go
>> instruction by instruction in all the moved blocks and correct the
>> reference to point to the arguments in the oldModule's new function, this
>> also sounds very messy and complicated.
>>
>>
>> Regards,
>> Daniel Moya
>>
>>
>>
>>
>> El dom., 2 de sep. de 2018 a la(s) 23:18, Ahmad Nouralizadeh Khorrami (
>> ahmad.llvm at gmail.com) escribió:
>>
>>> Hi Daniel,
>>> The answer was for your first thread. The benefits are outlined in the
>>> repository, but your problem is still there. I'm not sure. But this looks
>>> similar to my recent problem. I think that a bitcast will solve the
>>> problem. The types after the linking process may have different names but
>>> the same contents. The links to the answers are as follows:
>>> http://lists.llvm.org/pipermail/llvm-dev/2018-August/125413.html
>>>
>>> https://stackoverflow.com/questions/51894129/convert-function-pointer-call-to-function-call-at-the-ir-level
>>> Regards.
>>>
>>> On Sun, 2 Sep 2018 at 23:30, Daniel Moya <danielmscr1994 at gmail.com>
>>> wrote:
>>>
>>>> Hi Ahmad,
>>>>
>>>> What does that tool does besides what LLVM linker already does? I don't
>>>> think my problem is in linking both modules, I think LLVM linker does the
>>>> job for me, the issue is when changing the called function to call another
>>>> function (in the example previously provided, to change it from foo2 to
>>>> foo3, and adjusting the function parameter's references).
>>>>
>>>> Regards,
>>>> Daniel Moya
>>>>
>>>> El dom., 2 de sep. de 2018 a la(s) 17:00, Ahmad Nouralizadeh Khorrami (
>>>> ahmad.llvm at gmail.com) escribió:
>>>>
>>>>> Hi.
>>>>> Besides the LLVM linker, you can also use this tool:
>>>>> https://github.com/travitch/whole-program-llvm
>>>>> It links all the modules and produces a single module containing every
>>>>> function.
>>>>> Regards.
>>>>>
>>>>> On Sun, 2 Sep 2018 at 16:57, Daniel Moya via llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hello and thanks for the answer,
>>>>>>
>>>>>> I'm still facing issues, I'll do my best to explain my situation, as
>>>>>> I explained, I have two modules, each one with its own main and functions,
>>>>>> I would like to replace in the *oldModule* a function call that is
>>>>>> calling *foo2* (defined in *oldModule*) to instead call *foo3*,
>>>>>> which is defined in the *refModule. *So in summary, I have:
>>>>>>
>>>>>> 1. The original instruction call, defined in the main function of
>>>>>> the oldModule, who is a calling function to foo2, I'll name it
>>>>>> *oInst *(original Instruction)
>>>>>> 2. The "new" instruction call, defined in the main function of
>>>>>> the refModule, who is a calling function to foo3, I'll name it
>>>>>> *nInst* (new Instruction)
>>>>>> 3. The foo2 function definition, defined in the oldModule, I'll
>>>>>> name it *oFunc *(original Function)
>>>>>> 4. The foo3 function definition, defined in the refModule, I'll
>>>>>> name it *nFunc* (new Function)
>>>>>> 5. I have the parameters (or arguments?) of both functions, both
>>>>>> in the calling instruction and in the function's definition, which I'll
>>>>>> refer to as *p(oInst)*, *p(nInst)*, *p(oFunc)*, *p(nFunc) *(the
>>>>>> parameters of)
>>>>>> 6. For testing purposes, both foo2 and foo3 and defined
>>>>>> identical, same returning type, parameter's type and even the same
>>>>>> variable's name in the IR.
>>>>>>
>>>>>> So after calling the *llvm::LinkerlinkModules* function, I did:
>>>>>>
>>>>>> 1. First attempt:
>>>>>>
>>>>>> 1. llvm::CallInst *callOInst =
>>>>>> static_cast<llvm::CallInst*>(oInst); // I cast the* oInst* to a
>>>>>> llvm::CallInst
>>>>>> 2. callOInst->setCalledFunction(nFunc); // now *oInst* should
>>>>>> call nFunc
>>>>>>
>>>>>> Error:
>>>>>> Call parameter type does not match function signature!
>>>>>> %0 = load i32, i32* %a, align 4
>>>>>> i32 %call1 = call i32 @foo3(i32 %0, i32 %1)
>>>>>>
>>>>>> So even though the parameters are the same type, and defined
>>>>>> identically in both modules, the *p(oInst)* apparently does not
>>>>>> match the *p(nFunc)*.
>>>>>>
>>>>>> 2. Second attempt:
>>>>>>
>>>>>> 1. llvm::Instruction *nCloneInst = nInst->clone(); //Clone of the
>>>>>> *nInst*, to avoid remove it from the refModule
>>>>>> 2. nCloneInst->insertAfter(oInst); // I'll bring the nInst
>>>>>> because I know *p(nInst)* and *p(nFunc)* match
>>>>>> 3. nCloneInst->mutateType(oInst->getType()); //Idk why I have to
>>>>>> this, but necessary for next line
>>>>>> 4. oInst->replaceAllUsesWith(nCloneInst);
>>>>>> 5. oInst->dropAllReferences();
>>>>>> 6. oInst->eraseFromParent();
>>>>>>
>>>>>> Error:
>>>>>> Instruction does not dominate all uses!
>>>>>> %0 = load i32, i32* %a, align 4
>>>>>> %2 = call i32 @foo3(i32 %0, i32 %1)
>>>>>>
>>>>>> Great, now the *p(nInst)* are still referring to their definition in
>>>>>> the refModule, so either I bring those instructions too (which sounds
>>>>>> really messy) or somehow I change the *p(nInst)* to refer to the
>>>>>> instructions in oldModule, which in my case are actually defined the same
>>>>>> (but apparently the references don't change based on the name being the
>>>>>> same in both modules).
>>>>>>
>>>>>> 3. Third attempt:
>>>>>>
>>>>>> 1. The same 1-4 steps as before, from cloning instruction to
>>>>>> replaceAllUsesWith
>>>>>> 2. llvm::CallInst *callNInst =
>>>>>> static_cast<llvm::CallInst*>(nCloneInst);
>>>>>> 3. llvm::CallInst *callOInst =
>>>>>> static_cast<llvm::CallInst*>(oInst); // cast both *oInst* and
>>>>>> *nInst*
>>>>>> 4. for (unsigned int i = 0; i < callOInst->getNumArgOperands();
>>>>>> i++) { callNInst->setArgOperand(i,callOInst->getArgOperand(i)); } //replace
>>>>>> *p(nInst)* with *p(oInst)*
>>>>>> 5. The same 5-6 steps as before, drop and erase
>>>>>>
>>>>>> Error:
>>>>>> Call parameter type does not match function signature!
>>>>>> %0 = load i32, i32* %a, align 4
>>>>>> i32 %2 = call i32 @foo3(i32 %0, i32 %1)
>>>>>>
>>>>>> So back to the first problem, the *p(nInst) *(now converted to
>>>>>> *p(oInst)*) apparently does not match the *p(nFunc)*.
>>>>>>
>>>>>> I also looked into the *CloneFunctionInto *function, but I didn't
>>>>>> understand the arguments of it, and there's really no documentation or
>>>>>> examples that I could find on the internet. Specifically, I have troubles
>>>>>> with *llvm::SmallVectorImpl< llvm::ReturnInst *> &Returns *argument,
>>>>>> I don't know how to initialize it, it doesn't have a 0 argument constructor
>>>>>> and if I try:
>>>>>>
>>>>>> llvm::SmallVectorImpl< llvm::ReturnInst *> ReturnsArg =
>>>>>> llvm::SmallVectorImpl< llvm::ReturnInst *>(2); // Just as an example
>>>>>>
>>>>>> It says that constructor is protected. I didn't want to go further
>>>>>> since I'm clueless on how to properly use this function, and I'm even not
>>>>>> completely sure if it would fix all the troubles that I've been having with
>>>>>> the other three attempts.
>>>>>>
>>>>>> Btw, all these errors happen when I try to run (through JIT) the
>>>>>> module, a workaround that I know that I can do for all my attempts is just
>>>>>> to dump the module to a file, and then reload it and execute it (I know it
>>>>>> works since in both oldModule and refModule I use the same IR variable's
>>>>>> names) but I would like to do the work the *right* way and not
>>>>>> having to inefficiently dump a file just to reload it again and get all the
>>>>>> references right.
>>>>>>
>>>>>> Thanks for the help in advance, I'll be really grateful for any
>>>>>> advice or light in my situation.
>>>>>>
>>>>>> Regards,
>>>>>> Daniel Moya
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mar., 28 de ago. de 2018 a la(s) 20:26, Friedman, Eli (
>>>>>> efriedma at codeaurora.org) escribió:
>>>>>>
>>>>>>> On 8/27/2018 10:37 AM, Daniel Moya via llvm-dev wrote:
>>>>>>> > Hello LLVM Developers,
>>>>>>> >
>>>>>>> > I'm trying to replace a function defined in one module into
>>>>>>> another
>>>>>>> > module (different files). The first issue I ran into was that
>>>>>>> > llvm::Function does not have a method "moveBefore" or "moveAfter"
>>>>>>> as
>>>>>>> > the llvm::BasicBlock or llvm::Instruction do, so I figured I would
>>>>>>> > just move the BasicBlocks of the replacing function into the
>>>>>>> function
>>>>>>> > that was being replaced, and then eliminate the original
>>>>>>> BasicBlocks.
>>>>>>>
>>>>>>> Cross-module operations are tricky in general; I'd suggest using the
>>>>>>> Linker::linkModules API if possible.
>>>>>>>
>>>>>>> -Eli
>>>>>>>
>>>>>>> --
>>>>>>> Employee of Qualcomm Innovation Center, Inc.
>>>>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>>>>>> Linux Foundation Collaborative Project
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180904/bf369255/attachment.html>
More information about the llvm-dev
mailing list