I was working on ⚙ D81911 [ThinLTO] Work around getBaseObject returning null for alias-to-ifunc to try and fix
46340 – Null dereference when generating module summary index with alias-to-ifunc . 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.