[llvm-dev] [IR] Modelling of GlobalIFunc

[Teresa Johnson via llvm-dev]

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/20200908/6e5d9ed9/attachment.html>