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

>> 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?

vedant

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.  Which brings me to -- can you use hung off uses for this? 
These use lists can be resized on the
fly, so you should be able to add and remove prologue data on the fly.  If
you're using hung off uses, you'll probably
still need a descriptor to remember whether / which operands are prologue data
etc.

-- Sanjoy

>
> vedant

> 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.
>  Which brings me to -- can you use hung off uses for this?  These use lists
can be resized on the fly, so you should be able to add and remove prologue data
on the fly.  If you're using hung off uses, you'll probably still need a
descriptor to remember whether / which operands are prologue data etc.
Sure, this is another option.  It might be simplest.  I'd be
tempted to start with a 0/3 choice (if we allocate any hung-off
uses, allocate enough for all three operands) to simplify the
logic.  Although I can't remember right now whether that's
legal (having nullptr operands followed by real ones)...
>>>>>> Personalities are stored as ``optional`` Function
operands. We actually always
>>>>>> allocate the space for this ``optional`` operand:
there's a FIXME in the
>>>>>> destructor for Function about this.
Makes me wonder, why didn't we use hung off uses to begin with?
Do functions "usually" have personality functions, for some
definition of?