[llvm-dev] [IR] Modelling of GlobalIFunc

[Itay Bookstein via llvm-dev]

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