[PATCH] D110064: [SelectionDAG] Assume that a GlobalAlias may alias other global values

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