Displaying 7 results from an estimated 7 matches for "setprologuedata".
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
...ed to add
> prefix/prologue data after functions 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 f...
2015 Oct 12
3
[RFC] Clean up the way we store optional Function data
...re 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 exampl...
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
...ant 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...
2015 Oct 16
2
[RFC] Clean up the way we store optional Function data
...e 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
>>>...
2015 Oct 21
2
[RFC] Clean up the way we store optional Function data
...t;>>> 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 d...
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
2015 Oct 10
2
[RFC] Clean up the way we store optional Function data
Function's have three kinds of optional data: prefix data, prologue data, and
personalities. We don't have a consistent way of storing this data, IMO. This
RFC discusses a new way of managing optional data that makes llvm::Function
cleaner, more consistent, and a little smaller.
What do we do currently?
========================
Prefix and prologue data are attached to Functions via