[PATCH] D99051: [InstCombine] Stop folding inttoptr+bitcast if multiple uses

[Ruiling, Song via Phabricator via llvm-commits]

ruiling created this revision.
ruiling added reviewers: spatel, lebedev.ri, arsenm.
Herald added subscribers: hiraditya, arichardson.
ruiling requested review of this revision.
Herald added subscribers: llvm-commits, wdng.
Herald added a project: LLVM.

Don't combine a inttoptr followed by a bitcast to another pointer type if
the intermediate pointer has multiple uses. Such combine is very unfriendly
to later passes like ScalarEvolutionAnalysis and LoadStoreVectorizer. For
example, this may change the IR from:

  %p1 = inttoptr %addr to i32 *
  %i  = load i32, i32 * %p1

==> %p2 = bitcast i32 * %p1 to float *

  %p3 = getelementptr float, float * %p2, i64 1
  %f  = load float, float * %p3

into:

  %p1 = inttoptr %addr to i32 *

==> %p2 = inttoptr %addr to float *

  %i  = load i32, i32 * %p1
  %p3 = getelementptr float, float * %p2, i64 1
  %f  = load float, float * %p3

This causes above mentioned passes fail to reason that the two pointers
are consecutive, thus fail to vectorize the two loads.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99051

Files:
  llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
  llvm/test/Transforms/InstCombine/inttoptr_followed_by_bitcast.ll


Index: llvm/test/Transforms/InstCombine/inttoptr_followed_by_bitcast.ll
===================================================================
--- /dev/null
+++ llvm/test/Transforms/InstCombine/inttoptr_followed_by_bitcast.ll
@@ -0,0 +1,28 @@
+; RUN: opt < %s  -instcombine  -S | FileCheck %s
+
+define i32 @inttoptr_followed_by_bitcast(i32 %i0, i32 %i1, float %i2) {
+; CHECK-LABEL: @inttoptr_followed_by_bitcast(
+; CHECK:  [[PTR1:%.*]] = inttoptr i64 [[I:%.*]] to i32 addrspace(1)*
+; CHECK:  [[PTR2:%.*]] = bitcast i32 addrspace(1)* [[PTR1]] to float addrspace(1)*
+; CHECK:  [[F:%.*]] = load float, float addrspace(1)* [[PTR2]], align 4
+
+  %i3 = zext i32 %i0 to i64
+  %i4 = shl i32 %i1, 3
+  %i5 = and i32 %i4, -64
+  %i6 = zext i32 %i5 to i64
+  %i7 = add nuw nsw i64 %i3, %i6
+
+  %ip = inttoptr i64 %i7 to i32 addrspace(1)*
+  %fp = bitcast i32 addrspace(1)* %ip to float addrspace(1)*
+  %if0 = load float, float addrspace(1)* %fp, align 4
+
+  %ip2 = getelementptr i32, i32 addrspace(1)* %ip, i64 1
+  %i8 = load i32, i32 addrspace(1)* %ip2, align 4
+
+  %mul0 = fmul reassoc nnan nsz arcp contract afn float %if0, %i2
+
+  %ip3 = bitcast i32 addrspace(1)* %ip to float addrspace(1)*
+  store float %mul0, float addrspace(1)* %ip3, align 4
+
+  ret i32 %i8
+}
Index: llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
===================================================================
--- llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
+++ llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
@@ -271,6 +271,31 @@
       (Res == Instruction::PtrToInt && DstTy != SrcIntPtrTy))
     Res = 0;
 
+  // Don't combine a inttoptr followed by a bitcast to another pointer type if
+  // the intermediate pointer has multiple uses. Such combine is very unfriendly
+  // to later passes like ScalarEvolutionAnalysis and LoadStoreVectorizer. For
+  // example, this may change the IR from:
+  //
+  // %p1 = inttoptr %addr to i32 *
+  // %i  = load i32, i32 * %p1
+  // %p2 = bitcast i32 * %p1 to float *
+  // %p3 = getelementptr float, float * %p2, i64 1
+  // %f  = load float, float * %p3
+  //
+  // into:
+  //
+  // %p1 = inttoptr %addr to i32 *
+  // %p2 = inttoptr %addr to float *
+  // %i  = load i32, i32 * %p1
+  // %p3 = getelementptr float, float * %p2, i64 1
+  // %f  = load float, float * %p3
+  //
+  // This causes above mentioned passes fail to reason that the two pointers
+  // are consecutive, thus fail to vectorize the two loads.
+  if (firstOp == Instruction::IntToPtr && Res == Instruction::IntToPtr &&
+      !CI1->hasOneUse())
+    Res = 0;
+
   return Instruction::CastOps(Res);
 }
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D99051.332198.patch
Type: text/x-patch
Size: 2623 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210322/6abb6bcc/attachment.bin>