[PATCH] D65118: Analysis: Don't look through aliases when simplifying GEPs.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 22 20:16:37 PDT 2019


pcc added a comment.

Here is my brain dump on alias optimizations:

- The only case in which we can soundly replace an alias with the aliasee is when we know that both have the same value.
- This means that the transformation is only valid when both alias and aliasee are not preemptible (either at link time or runtime).
- But if we know this, there's no difference between taking the address of the alias and taking the address of the aliasee. Replacing one with the other will result in generating the exact same code.
- In fact, looking past aliases even when we are allowed to could be harmful from a QoI perspective:
  - Let's say that a compiler pass RAUWs an internal linkage global with an internal linkage alias pointing to a private linkage global (LowerTypeTests, WholeProgramDevirt and soon HWASAN all do this).
  - A later optimization pass that replaces references to the alias with references to the global will allow GlobalDCE to drop the alias, which means that the symbol is no longer in the symbol table, which could hurt debuggability.
- However, there's still a benefit in looking past aliases, but only in order to look at the *contents* (not the address) of the global.
- For example, the following is valid:

  @a = private constant i8* @x
  @b = linkonce_odr alias @a
  
  define void @foo() {
    %x = load i8*, i8** @b
    ret i8* %x ; may be replaced with ret i8* @x
  }

- So I think that the ideal final state is that looking past aliases should be opt-in and only allowed when a pass introduces no dependencies on the address of the aliasee.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65118





More information about the llvm-commits mailing list