[llvm-dev] [IR] Modelling of GlobalIFunc

[Duncan P. N. Exon Smith via llvm-dev]

For the specific problem hit below, it feels like another available approach would be to change GlobalIndirectSymbol to behave correctly for both GlobalAlias and GlobalIFunc, without changing the class hierarchy, by reducing its scope and deferring more to its derived classes (e.g., change getBaseObject() to do the right thing).

Can you comment further on the tradeoffs vs. the refactoring you’re proposing? (I see your argument that globalifunc shares some properties globalobject, but it’s not obvious to me that it’s more similar to globalobject than it is to globalalias, or that in aggregate code dealing with these classes will be cleaner after moving globalifunc over to the globalobject bucket.)

> On 2020-09-07, at 13:06, 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