[PATCH] D81911: [IR] Fix getBaseObject for GlobalAlias-to-GlobalIFunc

[Itay Bookstein via Phabricator via llvm-commits]

nextsilicon-itay-bookstein added a comment.

In D81911#2137237 <https://reviews.llvm.org/D81911#2137237>, @DmitryPolukhin wrote:

> I did a bit of archeology and it turns out that getBaseObejct was part of moved from GlobalAlias to GlobalIndirectSymbol in https://github.com/llvm/llvm-project/commit/95549497ec8b5269f0439f12859537b7371b7c90
>  It looks like the simplest solution is to handle nullptr from getBaseObejct in computeAliasSummary...


Doesn't that mean that getBaseObject is given two contradictory meanings, then?
On the one hand, from what you say, the base object should be able to "act in place of the enclosing object" => GlobalIFunc::getBaseObject() should return itself, since the resolver doesn't substitute for the symbol it's supposed to resolve.
On the other hand, from the expectations of code like DCE and SplitModule (in the commit you linked), the base object should tell you that these objects are "linked together" in some respect => GlobalIFunc::getBaseObject() should return the resolver, since they are 'inseparable' in that respect.

>From a types point of view, either of the two restores the idempotence getBaseObject().

But as far as this PR is concerned:

- Without this PR's changes, if you have Alias-to-IFunc, getBaseObject() on the Alias returns nullptr and getBaseObject() on the IFunc returns the resolver.
- If we put "return GI;" in findBaseObject(), getBaseObject() for the Alias returns the IFunc, but getBaseObject() on the IFunc returns the resolver.

Both cases are not idempotent :\


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81911/new/

https://reviews.llvm.org/D81911