llvm dev - Oct 2015 - [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 Function's
use list.

>  If so, you might want to consider using the "descriptor"
> functionality that was added recently[2].  It allows classes deriving
> from `llvm::User` to allocate an arbitrary number of bookkeeping bytes
> before the normal `Use &` array.  Instructions with operand bundles
> use these bytes to remember which where the individual operand bundles
> start and end, and an `llvm::Function` could easily use the extra
> storage to remember if / where optional operands like the personality
> function are in the `Use &` array.  And by making the operands part of
> the regular `Use &` array, functionality like RAUW that use Def-Use
> chains should Just Work(TM).
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?

vedant

> On 2015-Oct-12, at 09:01, Vedant Kumar <vsk at apple.com> wrote:
> 
> 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
Function's use list.
> 
> 
>> If so, you might want to consider using the "descriptor"
>> functionality that was added recently[2].  It allows classes deriving
>> from `llvm::User` to allocate an arbitrary number of bookkeeping bytes
>> before the normal `Use &` array.  Instructions with operand bundles
>> use these bytes to remember which where the individual operand bundles
>> start and end, and an `llvm::Function` could easily use the extra
>> storage to remember if / where optional operands like the personality
>> function are in the `Use &` array.  And by making the operands part
of
>> the regular `Use &` array, functionality like RAUW that use Def-Use
>> chains should Just Work(TM).
> 
> 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?

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