[PATCH] D88806: [SCEV] Model inttoptr and ptrtoint casts not as unknown, but as zext/trunc/self of unknown

Max Kazantsev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 8 01:56:40 PDT 2020


mkazantsev added a comment.

It is now always clear how this patch lead to all these changes in different tests. I can't say if all of them are correct. To make it more reviewable and get progress here, I'd ask for the following:

- Whever you see test updates adding things like `, align 1`, please run it without your patch and commit these changes as NFC. This will reduce the scope of changes greatly.
- A dedicated test file with `-analyze -scalar-evolution` with single inttoptr, single ptrtoint, their combinations with each other, geps and arithmetics. It should include corner cases (`nullptr`, negative addresses etc). That would show how this works in isolation;
- Introduce `inttoptr` and `ptrtoint` in two different patches. I share @nlopes 's concern about inttoptr and not really sure how it should work;

Also a question: how this is going to interact with non-integral pointer types (https://llvm.org/docs/LangRef.html#nointptrtype)? I never touched it, but seems that we will have such thing at some point.

Also it bugs me that the address space notion gets lost during this transform, not sure if it may have bad implications.



================
Comment at: llvm/test/Analysis/ScalarEvolution/no-wrap-add-exprs.ll:173
 ; CHECK:  %int.zext = zext i32 %int5 to i64
-; CHECK-NEXT:  -->  (1 + (zext i32 (4 + %int0) to i64))<nuw><nsw> U: [1,4294967294) S: [1,4294967297)
+; CHECK-NEXT:  --> (1 + (zext i32 (4 + (trunc i8* %ptr to i32)) to i64))<nuw><nsw> U: [1,4294967294) S: [1,4294967297)
 
----------------
I don't quite get how we ended up with this. Do we somehow know that `i8*` is wider than `i32`? Is it coming from default data layout or?..


================
Comment at: llvm/test/Other/constant-fold-gep.ll:184
 ; SCEV:   %t = bitcast i8* getelementptr (i8, i8* inttoptr (i32 1 to i8*), i32 -1) to i8*
-; SCEV:   -->  (-1 + inttoptr (i32 1 to i8*))
+; SCEV:   --> (-1 + (zext i32 1 to i64))<nsw> U: [0,1) S: [-1,4294967295)
 ; SCEV: Classifying expressions for: @goo1
----------------
Did the result type change here, or old type of `i8*` was also `i64`?


================
Comment at: llvm/test/Other/constant-fold-gep.ll:316
 ; SCEV:   %t = bitcast i64 mul (i64 ptrtoint (double* getelementptr (double, double* null, i32 1) to i64), i64 2310) to i64
-; SCEV:   -->  (2310 * sizeof(double))
+; SCEV:   --> (2310 * getelementptr (double, double* null, i32 1)) U: [0,-15) S: [-9223372036854775808,9223372036854775793)
 ; SCEV: Classifying expressions for: @fb
----------------
The old output here looks way more reasonable. Is this really what we want?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88806



More information about the llvm-commits mailing list