[PATCH] D99240: [ConstantFolding] Look through local aliases when simplify GEPs

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D99240#2651342 <https://reviews.llvm.org/D99240#2651342>, @aeubanks wrote:

> Ah I see, https://github.com/llvm/llvm-project/blob/61a55c8812e790842799ba1de5bd81fe8afb3b16/llvm/lib/Transforms/IPO/GlobalOpt.cpp#L2953. It only works if the aliasee is a global value. Extending globalopt to handle aliasees that may be a constant expression containing a global value, rather than just a global value, would probably work as well. Either way is fine by me.

Could you share (or maybe add to the test) the actual alias/gep structure you want to optimize? It would make sense to me to always replace aliases with local linkage, even if they don't directly point to a global value. For non-local (but non-interposable) linkage it may not be profitable to do this. (I guess it might not be universally profitable for local linkage either in that an expensive constant expression could be duplicated, but I think we usually assume that constant expressions are cheap.)



================
Comment at: llvm/lib/IR/Value.cpp:612-613
       V = cast<GlobalAlias>(V)->getAliasee();
+    } else if (StripKind == PSK_ZeroIndicesAndLocalAliases &&
+               isa<GlobalAlias>(V) && cast<GlobalAlias>(V)->hasLocalLinkage()) {
+      V = cast<GlobalAlias>(V)->getAliasee();
----------------
pcc wrote:
> aeubanks wrote:
> > pcc wrote:
> > > aeubanks wrote:
> > > > pcc wrote:
> > > > > rnk wrote:
> > > > > > I wonder if it would be safe to power up all of the other versions of pointer stripping to look through local aliases.
> > > > > I don't think we should. It wouldn't be safe to allow passes to replace `@alias` with `@aliasee` with this IR:
> > > > > ```
> > > > > @alias = internal alias @aliasee
> > > > > @aliasee = linkonce_odr global i32 42
> > > > > ```
> > > > > We should also avoid the QoI issue (missing symbol table entry) that would result from such replacement given this IR:
> > > > > ```
> > > > > @alias = internal alias @aliasee
> > > > > @aliasee = private global i32 42
> > > > > ```
> > > > Why is the first transform not safe?
> > > Because it would replace a reference to this object file's copy of `@aliasee` with a reference to the copy of `@aliasee` selected by the linker, and those could potentially be different (and have different addresses, which is observable).
> > It doesn't end up using the copy of `@aliasee` selected by the linker?
> > 
> > globalopt actually performs this transform:
> > ```
> > $ cat /tmp/y.ll
> > @alias = internal alias i32, i32* @aliasee
> > @aliasee = linkonce_odr global i32 42
> > 
> > define i32 @foo() {
> >   %i = load i32, i32* @alias
> >   ret i32 %i
> > }
> > $ opt -passes=globalopt /tmp/y.ll -S
> > @aliasee = linkonce_odr local_unnamed_addr global i32 42
> > 
> > define i32 @foo() local_unnamed_addr {
> >   %i = load i32, i32* @aliasee, align 4
> >   ret i32 %i
> > }
> > ```
> > It doesn't end up using the copy of @aliasee selected by the linker?
> 
> No, it doesn't. `@alias` is specifically a reference to this object file's copy of the data defined by the `@aliasee` global.
> 
> > globalopt actually performs this transform:
> 
> I think that's a bug then.
> Because it would replace a reference to this object file's copy of `@aliasee` with a reference to the copy of `@aliasee` selected by the linker, and those could potentially be different (and have different addresses, which is observable).

I don't think I understand the problem. Ignoring unnamed_addr, `@alias` and `@aliasee` are required to have the same address. If another copy of `@aliasee` is chosen by the linker, then `@alias` is required to point to that other copy, which is compatible with replacing uses of `@alias` with `@aliasee` in the first place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99240