[llvm-dev] [IR] Modelling of GlobalIFunc

[Dmitry Polukhin via llvm-dev]

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>