[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 10:41:28 PDT 2015



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


More information about the llvm-dev mailing list