[llvm-dev] [RFC] Clean up the way we store optional Function data
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 12 11:07:24 PDT 2015
Duncan P. N. Exon Smith wrote:
>> On 2015-Oct-12, at 10:41, Sanjoy Das<sanjoy at playingwithpointers.com> wrote:
>> Vedant Kumar wrote:
>>>>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.)
>>>>> Could someone else chime in on what they'd like to see?
>>>> Sanjoy's idea makes sense to me, but only if we never need 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 future patches which add prefix/prologue data to Functions on the fly by taking this approach?
>> You should always be able to create a new `llvm::Function` instance (and RAUW it in) if you want to add prefix/prologue data to functions after they've been created; just like you have to do today for any other `llvm::User`s that do not have hung off uses.
> It's possible, but a lot more involved with `Function`s. Besides
> RAUW, you need to transfer over all the basic blocks.
> This seems kind of wrong to me, if we expect it to happen.
Ah, I didn't know that `BasicBlock`s keep a direct pointer to their
parent function. I agree that moving over all the BasicBlocks is
More information about the llvm-dev