[PATCH] D127503: [InstSimplify] Update GEP test to use opaque pointers

[Nikita Popov via Phabricator via llvm-commits]

nikic created this revision.
nikic added a reviewer: opaque-pointers.
Herald added a project: All.
nikic requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

With opaque pointers, we end up merging these GEPs and dropping the inrange attribute (in the last two cases). This did not happen previously, because typed pointers use less powerful GEP folding logic.

I'm a bit unsure whether this is something we need to be concerned about or not. I believe that generally our stance is that we should perform folds even if this requires losing poison-generating flags like inrange.

We can either a) accept this as-is, b) try to inhibit folding if it requires dropping inrange or c) try to fold to poison if we know that inrange is going to be violated.


https://reviews.llvm.org/D127503

Files:
  llvm/test/Transforms/InstSimplify/ConstProp/gep.ll


Index: llvm/test/Transforms/InstSimplify/ConstProp/gep.ll
===================================================================
--- llvm/test/Transforms/InstSimplify/ConstProp/gep.ll
+++ llvm/test/Transforms/InstSimplify/ConstProp/gep.ll
@@ -5,27 +5,27 @@
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 
-%struct.A = type { i32 (...)** }
+%struct.A = type { ptr }
 
- at vt = external global [3 x i8*]
+ at vt = external global [3 x ptr]
 
-define i32 (...)** @f0() {
+define ptr @f0() {
 ; CHECK-LABEL: @f0(
-; CHECK-NEXT:    ret i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, inrange i64 0, i64 2) to i32 (...)**)
+; CHECK-NEXT:    ret ptr getelementptr inbounds ([3 x ptr], ptr @vt, inrange i64 0, i64 2)
 ;
-  ret i32 (...)** getelementptr (i32 (...)*, i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, inrange i64 0, i64 1) to i32 (...)**), i64 1)
+  ret ptr getelementptr (ptr, ptr getelementptr inbounds ([3 x ptr], ptr @vt, inrange i64 0, i64 1), i64 1)
 }
 
-define i32 (...)** @f1() {
+define ptr @f1() {
 ; CHECK-LABEL: @f1(
-; CHECK-NEXT:    ret i32 (...)** getelementptr (i32 (...)*, i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, i64 0, inrange i64 1) to i32 (...)**), i64 1)
+; CHECK-NEXT:    ret ptr getelementptr inbounds ([3 x ptr], ptr @vt, i64 0, i64 2)
 ;
-  ret i32 (...)** getelementptr (i32 (...)*, i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, i64 0, inrange i64 1) to i32 (...)**), i64 1)
+  ret ptr getelementptr (ptr, ptr getelementptr inbounds ([3 x ptr], ptr @vt, i64 0, inrange i64 1), i64 1)
 }
 
-define i32 (...)** @f2() {
+define ptr @f2() {
 ; CHECK-LABEL: @f2(
-; CHECK-NEXT:    ret i32 (...)** getelementptr (i32 (...)*, i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, i64 0, inrange i64 1) to i32 (...)**), i64 3)
+; CHECK-NEXT:    ret ptr getelementptr ([3 x ptr], ptr @vt, i64 1, i64 1)
 ;
-  ret i32 (...)** getelementptr (i32 (...)*, i32 (...)** bitcast (i8** getelementptr inbounds ([3 x i8*], [3 x i8*]* @vt, i64 0, inrange i64 1) to i32 (...)**), i64 3)
+  ret ptr getelementptr (ptr, ptr getelementptr inbounds ([3 x ptr], ptr @vt, i64 0, inrange i64 1), i64 3)
 }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D127503.435921.patch
Type: text/x-patch
Size: 2310 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220610/2ca26a1a/attachment.bin>