[PATCH] D107249: [GlobalOpt] Don't optimize out non-preemptible alias if aliasee may be preemptible

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

This seems awfully confusing, and almost completely undocumented in LangRef.

If I'm understanding correctly, when you have an alias that refers to a global, the alias doesn't refer to a global symbol.  It instead refers to the content of the global, as emitted into the object file.  So resolving an alias that refers to a symbol that has weak linkage, or default visibility, can have weird effects: the linker might end up resolving the symbol differently.

So I guess I have two questions:

1. If we have a definition that isn't weak or interposable, but has default linkage, would it make sense to teach the backend to use an alias to refer to the global?  So we don't have to worry about it going through the PLT or whatever.  Maybe this would explode somehow?
2. Can we forbid aliases that refer to globals that are interposable, or use weak linkage?  In theory, this prohibition doesn't cause any loss of generality in IR: we can turn a weak definition into an alias pointing to an internal definition, which should be essentially equivalent.

I'm not too concerned about high-quality optimizations for aliases.  I'm mostly just concerned that it isn't clear what optimizations are legal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107249