[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 14:52:21 PDT 2019


pcc created this revision.
pcc added a reviewer: tejohnson.
Herald added subscribers: hiraditya, Prazek.
Herald added a project: LLVM.

It is not safe in general to replace an alias in a GEP with its aliasee
if the alias can be replaced with another definition (i.e. via strong/weak
resolution (linkonce_odr) or via symbol interposition (default visibility
in ELF)) while the aliasee cannot. An example of how this can go wrong is
in the included test case.

I was concerned that this might be a load-bearing misoptimization (it's
possible for us to use aliases to share vtables between base and derived
classes, and on Windows, vtable symbols will always be aliases in RTTI
mode, so this change could theoretically inhibit trivial devirtualization
in some cases), so I built Chromium for Linux and Windows with and without
this change. The file sizes of the resulting binaries were identical, so it
doesn't look like this is going to be a problem.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65118

Files:
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/test/Analysis/ConstantFolding/gep-alias.ll


Index: llvm/test/Analysis/ConstantFolding/gep-alias.ll
===================================================================
--- /dev/null
+++ llvm/test/Analysis/ConstantFolding/gep-alias.ll
@@ -0,0 +1,17 @@
+; RUN: opt -instcombine -S -o - %s | FileCheck %s
+; Test that we don't replace an alias with its aliasee when simplifying GEPs.
+; In this test case the transformation is invalid because it replaces the
+; reference to the symbol "b" (which refers to whichever instance of "b"
+; was chosen by the linker) with a reference to "a" (which refers to the
+; specific instance of "b" in this module).
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+ at a = internal global [3 x i8*] zeroinitializer
+ at b = linkonce_odr alias [3 x i8*], [3 x i8*]* @a
+
+define i8** @f() {
+  ; CHECK: ret i8** getelementptr ([3 x i8*], [3 x i8*]* @b, i32 0, i32 1)
+  ret i8** getelementptr ([3 x i8*], [3 x i8*]* @b, i32 0, i32 1)
+}
Index: llvm/lib/Analysis/ConstantFolding.cpp
===================================================================
--- llvm/lib/Analysis/ConstantFolding.cpp
+++ llvm/lib/Analysis/ConstantFolding.cpp
@@ -784,7 +784,7 @@
 Constant* StripPtrCastKeepAS(Constant* Ptr, Type *&ElemTy) {
   assert(Ptr->getType()->isPointerTy() && "Not a pointer type");
   auto *OldPtrTy = cast<PointerType>(Ptr->getType());
-  Ptr = Ptr->stripPointerCasts();
+  Ptr = cast<Constant>(Ptr->stripPointerCastsNoFollowAliases());
   auto *NewPtrTy = cast<PointerType>(Ptr->getType());
 
   ElemTy = NewPtrTy->getPointerElementType();


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D65118.211203.patch
Type: text/x-patch
Size: 1584 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190722/7a820357/attachment.bin>


More information about the llvm-commits mailing list