[PATCH] D110064: [SelectionDAG] Assume that a GlobalAlias may alias other global values
Nirav Dave via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 22 08:21:29 PDT 2021
niravd added a comment.
Can you add a codegen test for PR51878? The example listed in your message should do.
Once I think with the follow up, this should be good to go.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGAddressAnalysis.cpp:155
+ // global values and at least one is a GlobalAlias.
+ if (IsGV0 && IsGV1 &&
+ (isa<GlobalAlias>(cast<GlobalAddressSDNode>(
----------------
bjope wrote:
> niravd wrote:
> > It looks like we can walk the GlobalAlias to the referenced object. If so, we should fully walk to a non-alias global instead.
> >
> As I wrote in the desciption "In the future we might improve this with a deeper analysis to look at the aliasee for the GlobalAlias etc. But that is a bit more complicated considering that we could have 'local_unnamed_addr' and situations with several 'alias' variables.".
>
> I'd actually prefer doing a bugfix that I'm confortable with. And I didn't quite understand the part about "Aliases that are not unnamed_addr are guaranteed to have the same address as the aliasee expression. unnamed_addr ones are only guaranteed to point to the same content." from https://llvm.org/docs/LangRef.html#aliases .
>
> But if my approach was too naive and defensive, then I wonder why we have references to GlobalAlias:es in the IR in the first place. Couldn't we just reference the aliasee instead (leaving the GlobalAlias declaration as an unused declaration)?
I don't remember why this clause was neces
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110064/new/
https://reviews.llvm.org/D110064
More information about the llvm-commits
mailing list