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

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 3 08:51:24 PDT 2020


tejohnson added a comment.

In D81911#2254050 <https://reviews.llvm.org/D81911#2254050>, @nextsilicon-itay-bookstein wrote:

> The problem with what @DmitryPolukhin suggested (which he later acknowledged in an additional comment), is that getBaseObject() returns a GlobalObject, but GlobalIFunc does not inherit from GlobalObject, so that can't compile.
>
> I get a sense that GlobalIFunc should derive directly from GlobalObject (since it should be a valid final target for aliases), instead of GlobalIndirectSymbol; but that's a pretty big, cross-cutting change which I'm not even sure 100% makes sense :\

Oh I see. Hmm, there seems to be a fundamental issue with the way IFunc are currently represented, assuming it is legal to have an alias to ifunc (I don't see why not), and if it is not correct to return the ifunc resolver in this case (not sure).

How about this:

1. For now, to fix your immediate issue, change computeAliasSummary so that if getBaseObject returns null, then you see if you can cast the getAliasee result to GlobalIFunc and use that as the Aliasee (which needs to be made type GlobalValue instead of GlobalObject, which is fine since we just call getGUID on it and that's defined on GlobalValue). (Note there is still is the related problem shown in D82745 <https://reviews.llvm.org/D82745>.)

1. Start an llvm-dev thread on the higher level issue of whether GlobalIFunc should be derived from GlobalIndirectSymbol vs GlobalObject with a summary of the discussion/issues here.


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

https://reviews.llvm.org/D81911



More information about the llvm-commits mailing list