Duncan P. N. Exon Smith via llvm-dev
2015-Oct-12 18:00 UTC
[llvm-dev] [RFC] Clean up the way we store optional Function data
> 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?
Sanjoy Das via llvm-dev
2015-Oct-12 18:07 UTC
[llvm-dev] [RFC] Clean up the way we store optional Function data
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
David Majnemer via llvm-dev
2015-Oct-12 18:44 UTC
[llvm-dev] [RFC] Clean up the way we store optional Function data
On Mon, Oct 12, 2015 at 11:00 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> 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. > > > 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? >Depends. In C++? It's pretty common to have objects which have non-trivial destructors on the stack which means calling a function will be an invoke which will require the function to have a personality. In C? It's pretty rare. You'd need something like __attribute__((cleanup)) to do it, the most common source of this will be something like pthread_cleanup_push. If I recall correctly, Julia sets the personality on functions regardless of whether or not there are any invokes, they need the AsmPrinter to scribble something down. I can't say for other languages (Rust, etc.). From what I understand, Swift doesn't use landingpad for EH so they wouldn't need the personality set.> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151012/807f82bb/attachment.html>
Sanjoy Das via llvm-dev
2015-Oct-12 19:15 UTC
[llvm-dev] [RFC] Clean up the way we store optional Function data
David Majnemer wrote:> > > On Mon, Oct 12, 2015 at 11:00 AM, Duncan P. N. Exon Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 2015-Oct-12, at 10:41, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto: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? > > > Depends. In C++? It's pretty common to have objects which have > non-trivial destructors on the stack which means calling a function will > be an invoke which will require the function to have a personality. In > C? It's pretty rare. You'd need something like __attribute__((cleanup)) > to do it, the most common source of this will be something > like pthread_cleanup_push. If I recall correctly, Julia sets the > personality on functions regardless of whether or not there are any > invokes, they need the AsmPrinter to scribble something down. I can't > say for other languages (Rust, etc.). From what I understand, Swift > doesn't use landingpad for EH so they wouldn't need the personality set.Most functions we emit from our Java frontend have personalities. -- Sanjoy> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >