[llvm-dev] [RFC] Clean up the way we store optional Function data

[Sanjoy Das via llvm-dev]

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 
undesirable. :)

-- Sanjoy