[PATCH] D89456: [SCEV] Introduce SCEVPtrToIntExpr (PR46786)

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Oct 18 22:33:52 PDT 2020


efriedma added inline comments.


================
Comment at: llvm/test/Analysis/ScalarEvolution/max-backedge-taken-count-guard-info.ll:534
 ; CHECK-NEXT:    %text.addr.5 = phi i8* [ %incdec.ptr112, %while.cond111 ], [ null, %while.body ]
-; CHECK-NEXT:    --> {0,+,-1}<nw><%while.cond111> U: full-set S: full-set Exits: <<Unknown>> LoopDispositions: { %while.cond111: Computable, %while.body: Variant }
+; CHECK-NEXT:    --> {null,+,-1}<nw><%while.cond111> U: full-set S: full-set Exits: <<Unknown>> LoopDispositions: { %while.cond111: Computable, %while.body: Variant }
 ; CHECK-NEXT:    %incdec.ptr112 = getelementptr inbounds i8, i8* %text.addr.5, i64 -1
----------------
mkazantsev wrote:
> What's the type of the AddRec here? Is it an integral-type AddRec with pointer base? If so, this will be a source of various bugs because the code relies on fact that AddRec's type matches Base's type in many places.
Should be a pointer-type addrec; it's treating "null" as an opaque pointer.


================
Comment at: polly/test/Isl/CodeGen/pointer-type-expressions.ll:36
 
-; CHECK:      if (P <= -1 || P >= 1)
-; CHECK-NEXT:   for (int c0 = 0; c0 < N; c0 += 1)
-; CHECK-NEXT:     Stmt_store(c0);
-
-; CODEGEN-LABEL: polly.cond:
-; CODEGEN-NEXT:   %[[R1:[0-9]*]] = ptrtoint float* %P to i64
-; CODEGEN-NEXT:   %[[R2:[0-9]*]] = icmp sle i64 %[[R1]], -1
-; CODEGEN-NEXT:   %[[R3:[0-9]*]] = ptrtoint float* %P to i64
-; CODEGEN-NEXT:   %[[R4:[0-9]*]] = icmp sge i64 %[[R3]], 1
-; CODEGEN-NEXT:   %[[R5:[0-9]*]] = or i1 %[[R2]], %[[R4]]
-; CODEGEN-NEXT:   br i1 %[[R5]]
+; CHECK:      if (1 && 0 == ((p_1 >= P + 1 && N >= 1152921504606846977) || (P >= p_1 + 1 && N >= 1152921504606846977)))
+; CHECK-EMPTY:
----------------
mkazantsev wrote:
> Regression.
I suspect the change to null handling is changing the way the icmp is analyzed; should be easy to fix?  I'll try to find time to look in the next couple days.


================
Comment at: polly/test/ScopInfo/multidim_2d_with_modref_call_2.ll:56
 ; CHECK-NEXT:                [tmp14, p_1] -> { Stmt_bb17[i0] -> MemRef_arg4[o0] };
-; CHECK-NEXT:            MustWriteAccess :=	[Reduction Type: NONE] [Scalar: 0]
+; CHECK-NEXT:            ReadAccess :=       [Reduction Type: NONE] [Scalar: 0]
+; CHECK-NEXT:                [tmp14, p_1] -> { Stmt_bb17[i0] -> MemRef3[o0] };
----------------
mkazantsev wrote:
> Regression.
Is it?  As far as I can tell, the llvm.gcread is actually loading from a null pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89456



More information about the llvm-commits mailing list