Displaying 9 results from an estimated 9 matches for "setpersonalityfn".
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
...are created. Are there any places
> where we need/want to add them after the fact?
I think so. I see:
LinkModules.cpp: Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap,
BitcodeReader.cpp: FunctionPrologueWorklist.back().first->setPrologueData(C);
InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality);
Some of these sites could be refactored so that the Functions are created with the prefix/prologue data they need. I don't think that's possible for personality functions (see my third example).
Would we inhibit any future patches which add prefix/prologue data to Func...
2015 Oct 21
2
[RFC] Clean up the way we store optional Function data
I've done some measurements on this.
The test program I have just calls Function::Create(), F->setPersonalityFn(), and then F->eraseFromParent() in a loop 2^20 times.
Results:
pre-patch --- min: 1.10s max: 1.13s avg: 1.11s
post-patch --- min: 1.26s max: 1.35s avg: 1.29s
So we expect to lose 0.2 seconds per 1 million functions (with personality functions) in a project. I've only...
2015 Oct 12
3
[RFC] Clean up the way we store optional Function data
.../want to add them after the fact?
>>
>> I think so. I see:
>>
>> LinkModules.cpp: Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap,
>> BitcodeReader.cpp: FunctionPrologueWorklist.back().first->setPrologueData(C);
>> InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality);
>>
>> Some of these sites could be refactored so that the Functions are created with the prefix/prologue data they need. I don't think that's possible for personality functions (see my third example).
>>
>> Would we inhibit any future patches wh...
2015 Oct 16
2
[RFC] Clean up the way we store optional Function data
...t;>>>>
>>>>> LinkModules.cpp:
>>> Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap,
>>>>> BitcodeReader.cpp:
>>> FunctionPrologueWorklist.back().first->setPrologueData(C);
>>>>> InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality);
>>>>>
>>>>> Some of these sites could be refactored so that the Functions are
>>> created with the prefix/prologue data they need. I don't think
>>> that's possible for personality functions (see my third example).
>...
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
...I think so. I see:
> > >
> > > LinkModules.cpp:
> Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap,
> > > BitcodeReader.cpp:
> FunctionPrologueWorklist.back().first->setPrologueData(C);
> > > InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality);
> > >
> > > Some of these sites could be refactored so that the Functions are
> created with the prefix/prologue data they need. I don't think
> that's possible for personality functions (see my third example).
> > >
&...
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
Hi Sanjoy,
> I don't know how prologue and prefix data is used -- is it correct to
> say that you're basically trying to give `llvm::Function` s some
> "optional" operands, and that you know during construction of an
> `llvm::Function` how many optional operands the `llvm::Function` will
> need[1]?
Yep. Though not operands exactly, since they wouldn't be in
2018 Sep 06
2
Replacing a function from one module into another one
...ferences();
fOld->deleteBody();
llvm::ValueToValueMapTy VMap;
populateVMap(VMap, fOld, fNew);
bool ModuleArg = true;
llvm::SmallVector<llvm::ReturnInst*, 8> Returns;
llvm::CloneFunctionInto(fOld, fNew, VMap, ModuleArg, Returns);
if (fNew->hasPersonalityFn())
fOld->setPersonalityFn(llvm::MapValue(fNew->getPersonalityFn(), VMap));
}
void replaceFunctions(std::string oldFuncName, std::string newFuncName) {
llvm::SMDiagnostic origErr;
llvm::LLVMContext origContext;
std::unique_ptr<llvm::Module> origMod =
(llvm::parseIRFile(originalFileName, origErr, origContext))...
2018 Sep 06
2
Replacing a function from one module into another one
...ld->dropAllReferences();
fOld->deleteBody();
llvm::ValueToValueMapTy VMap;
populateVMap(VMap, fOld, fNew);
bool ModuleArg = true;
llvm::SmallVector<llvm::ReturnInst*, 8> Returns;
llvm::CloneFunctionInto(fOld, fNew, VMap, ModuleArg, Returns);
if (fNew->hasPersonalityFn())
fOld->setPersonalityFn(llvm::MapValue(fNew->getPersonalityFn(), VMap));
But after running the code, I still get the error: *Use still stuck around
after Def is destroyed*
Which means that the instructions moved from *fNew* still refer to the
arguments of *fNew* instead of the "mapped" (supposedly) ones in...
2018 Sep 04
2
Replacing a function from one module into another one
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