Dmitry Polukhin via llvm-dev
2020-Sep-10 12:15 UTC
[llvm-dev] [IR] Modelling of GlobalIFunc
> * Calling getBaseObject() on a GlobalIFunc returns its resolver function.I still don't understand how it can happen looking to the code ( https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). I don't have a strong opinion here because deriving GlobalIFunc from GlobalObject does make some sense. At the same time from implementation point of view there were lots of similarities between GlobalAlias and GlobalIFunc (in the most case they should be handled identically or very similarly). getBaseObject method in initial implementation belonged to GlobalAlias only. David moved it to GlobalIndirectSymbol in https://reviews.llvm.org/rG95549497ec8b5269f0439f12859537b7371b7c90 but unfortunately I cannot find corresponding review and discussion. On Tue, Sep 8, 2020 at 6:22 PM Teresa Johnson <tejohnson at google.com> wrote:> Thanks Itay for summarizing the discussion on D81911. Directly adding a > few folks either involved with the discussion there (Dmitry, who originally > ported the gcc implementation to clang/llvm), or who have implemented other > patches relating to IFunc support in llvm (Peter). > > Teresa > > On Mon, Sep 7, 2020 at 10:07 AM Itay Bookstein via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was working on https://reviews.llvm.org/D81911 to try and fix >> https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review >> process we happened upon a design limitation or perhaps a potential >> mis-modelling of GlobalIFunc in the IR object hierarchy, which leads >> to some problems in LTO flows. >> >> To summarize, as it currently stands (and in the hopes of faithfully >> representing the conclusions of that discussion): >> * Calling getBaseObject() on a GlobalAlias whose aliasee is a >> GlobalIFunc currently returns null. >> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. >> * This causes computeAliasSummary in ModuleSummaryAnalysis to crash on >> a null dereference for an alias-to-ifunc situation. >> * A GlobalIFunc and its resolver are *not* interchangeable: at the >> interface level, they have different signatures (conceptually, the >> IFunc has the same signature of the function pointer that the resolver >> potentially returns, not of the resolver itself). >> * It makes sense for the IFunc to be its own base object (which is >> GlobalObject-like-behavior), but type-hierarchy-wise it can't. This is >> because GlobalIFunc derives from GlobalIndirectSymbol which derives >> directly from GlobalValue, and therefore it is not a GlobalObject. >> >> Would it make sense for GlobalIFunc to derive from GlobalObject >> instead of GlobalIndirectSymbol? If so, GlobalIndirectSymbol would >> lose its purpose somewhat, and could be merged into GlobalAlias. It >> would, however, require updating a considerable amount of code. >> >> ~Itay >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200910/4e833871/attachment.html>
Itay Bookstein via llvm-dev
2020-Sep-10 20:48 UTC
[llvm-dev] [IR] Modelling of GlobalIFunc
> I still don't understand how it can happen looking to the code (https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc).That is because that's findBaseObject(), not getBaseObject(): if you call getBaseObject() on a GlobalIFunc you'll get the GlobalIndirectSymbol::getBaseObject() implementation (https://github.com/llvm/llvm-project/blob/cb19e8c6d192a108b72ab07362921864a9e244f9/llvm/lib/IR/Globals.cpp#L463), which passes getOperand(0) - the resolver - as the first parameter to findBaseObject(). Because the resolver is a Function, findBaseObject() simply returns it as-is. Just checked in gdb ;) On Thu, Sep 10, 2020 at 3:16 PM Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote:> > > * Calling getBaseObject() on a GlobalIFunc returns its resolver function. > > I still don't understand how it can happen looking to the code (https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). > > I don't have a strong opinion here because deriving GlobalIFunc from GlobalObject does make some sense. At the same time from implementation point of view there were lots of similarities between GlobalAlias and GlobalIFunc (in the most case they should be handled identically or very similarly). getBaseObject method in initial implementation belonged to GlobalAlias only. David moved it to GlobalIndirectSymbol in https://reviews.llvm.org/rG95549497ec8b5269f0439f12859537b7371b7c90 but unfortunately I cannot find corresponding review and discussion. > > On Tue, Sep 8, 2020 at 6:22 PM Teresa Johnson <tejohnson at google.com> wrote: >> >> Thanks Itay for summarizing the discussion on D81911. Directly adding a few folks either involved with the discussion there (Dmitry, who originally ported the gcc implementation to clang/llvm), or who have implemented other patches relating to IFunc support in llvm (Peter). >> >> Teresa >> >> On Mon, Sep 7, 2020 at 10:07 AM Itay Bookstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I was working on https://reviews.llvm.org/D81911 to try and fix >>> https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review >>> process we happened upon a design limitation or perhaps a potential >>> mis-modelling of GlobalIFunc in the IR object hierarchy, which leads >>> to some problems in LTO flows. >>> >>> To summarize, as it currently stands (and in the hopes of faithfully >>> representing the conclusions of that discussion): >>> * Calling getBaseObject() on a GlobalAlias whose aliasee is a >>> GlobalIFunc currently returns null. >>> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. >>> * This causes computeAliasSummary in ModuleSummaryAnalysis to crash on >>> a null dereference for an alias-to-ifunc situation. >>> * A GlobalIFunc and its resolver are *not* interchangeable: at the >>> interface level, they have different signatures (conceptually, the >>> IFunc has the same signature of the function pointer that the resolver >>> potentially returns, not of the resolver itself). >>> * It makes sense for the IFunc to be its own base object (which is >>> GlobalObject-like-behavior), but type-hierarchy-wise it can't. This is >>> because GlobalIFunc derives from GlobalIndirectSymbol which derives >>> directly from GlobalValue, and therefore it is not a GlobalObject. >>> >>> Would it make sense for GlobalIFunc to derive from GlobalObject >>> instead of GlobalIndirectSymbol? If so, GlobalIndirectSymbol would >>> lose its purpose somewhat, and could be merged into GlobalAlias. It >>> would, however, require updating a considerable amount of code. >>> >>> ~Itay >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com |-- Itay Bookstein Software Engineer NEXTSILICON T. + 972 50 594 0880
Dmitry Polukhin via llvm-dev
2020-Sep-11 20:56 UTC
[llvm-dev] [IR] Modelling of GlobalIFunc
Oh, you are right. My mistake, I expected that findBaseObject is called on `this` so first hope and other work the same. It would be a good thing to do anyway because it will help to detect loops earlier and make getBaseObject consistent. On Thu, Sep 10, 2020 at 9:49 PM Itay Bookstein < itay.bookstein at nextsilicon.com> wrote:> > I still don't understand how it can happen looking to the code ( > https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). > I believe it should return nullptr (the same as if you call it from > GlobalAlias that refers to GlobalIFunc). > > That is because that's findBaseObject(), not getBaseObject(): if you > call getBaseObject() on a GlobalIFunc you'll get the > GlobalIndirectSymbol::getBaseObject() implementation > ( > https://github.com/llvm/llvm-project/blob/cb19e8c6d192a108b72ab07362921864a9e244f9/llvm/lib/IR/Globals.cpp#L463 > ), > which passes getOperand(0) - the resolver - as the first parameter to > findBaseObject(). Because the resolver is a Function, findBaseObject() > simply returns it as-is. Just checked in gdb ;) > > > On Thu, Sep 10, 2020 at 3:16 PM Dmitry Polukhin > <dmitry.polukhin at gmail.com> wrote: > > > > > * Calling getBaseObject() on a GlobalIFunc returns its resolver > function. > > > > I still don't understand how it can happen looking to the code ( > https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). > I believe it should return nullptr (the same as if you call it from > GlobalAlias that refers to GlobalIFunc). > > > > I don't have a strong opinion here because deriving GlobalIFunc from > GlobalObject does make some sense. At the same time from implementation > point of view there were lots of similarities between GlobalAlias and > GlobalIFunc (in the most case they should be handled identically or very > similarly). getBaseObject method in initial implementation belonged to > GlobalAlias only. David moved it to GlobalIndirectSymbol in > https://reviews.llvm.org/rG95549497ec8b5269f0439f12859537b7371b7c90 but > unfortunately I cannot find corresponding review and discussion. > > > > On Tue, Sep 8, 2020 at 6:22 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> > >> Thanks Itay for summarizing the discussion on D81911. Directly adding a > few folks either involved with the discussion there (Dmitry, who originally > ported the gcc implementation to clang/llvm), or who have implemented other > patches relating to IFunc support in llvm (Peter). > >> > >> Teresa > >> > >> On Mon, Sep 7, 2020 at 10:07 AM Itay Bookstein via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >>> > >>> I was working on https://reviews.llvm.org/D81911 to try and fix > >>> https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review > >>> process we happened upon a design limitation or perhaps a potential > >>> mis-modelling of GlobalIFunc in the IR object hierarchy, which leads > >>> to some problems in LTO flows. > >>> > >>> To summarize, as it currently stands (and in the hopes of faithfully > >>> representing the conclusions of that discussion): > >>> * Calling getBaseObject() on a GlobalAlias whose aliasee is a > >>> GlobalIFunc currently returns null. > >>> * Calling getBaseObject() on a GlobalIFunc returns its resolver > function. > >>> * This causes computeAliasSummary in ModuleSummaryAnalysis to crash on > >>> a null dereference for an alias-to-ifunc situation. > >>> * A GlobalIFunc and its resolver are *not* interchangeable: at the > >>> interface level, they have different signatures (conceptually, the > >>> IFunc has the same signature of the function pointer that the resolver > >>> potentially returns, not of the resolver itself). > >>> * It makes sense for the IFunc to be its own base object (which is > >>> GlobalObject-like-behavior), but type-hierarchy-wise it can't. This is > >>> because GlobalIFunc derives from GlobalIndirectSymbol which derives > >>> directly from GlobalValue, and therefore it is not a GlobalObject. > >>> > >>> Would it make sense for GlobalIFunc to derive from GlobalObject > >>> instead of GlobalIndirectSymbol? If so, GlobalIndirectSymbol would > >>> lose its purpose somewhat, and could be merged into GlobalAlias. It > >>> would, however, require updating a considerable amount of code. > >>> > >>> ~Itay > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> > >> -- > >> Teresa Johnson | Software Engineer | tejohnson at google.com | > > > > -- > > > > > Itay Bookstein > > Software Engineer > > > NEXTSILICON > > > T. + 972 50 594 0880 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200911/8e82d692/attachment.html>