[PATCH] D89692: [SCEV] SCEVPtrToIntExpr simplifications
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 26 05:16:13 PDT 2020
lebedev.ri marked an inline comment as done.
lebedev.ri added a comment.
@mkazantsev thank you for taking a look!
================
Comment at: llvm/test/Analysis/ScalarEvolution/ptrtoint.ll:501
; X32-NEXT: %i9 = ptrtoint i32* %i7 to i64
-; X32-NEXT: --> (zext i32 (ptrtoint i32* {%arg,+,4}<nuw><%bb6> to i32) to i64) U: [0,4294967296) S: [0,4294967296) Exits: (zext i32 (ptrtoint i32* ((4 * ((-4 + (-1 * %arg) + %arg1) /u 4))<nuw> + %arg) to i32) to i64) LoopDispositions: { %bb6: Computable }
+; X32-NEXT: --> {(zext i32 (ptrtoint i32* %arg to i32) to i64),+,4}<nuw><%bb6> U: [0,8589934588) S: [0,8589934588) Exits: ((zext i32 (ptrtoint i32* %arg to i32) to i64) + (4 * ((zext i32* (-4 + (-1 * %arg) + %arg1) to i64) /u 4))<nuw><nsw>) LoopDispositions: { %bb6: Computable }
; X32-NEXT: %i10 = sub i64 %i9, %i4
----------------
mkazantsev wrote:
> Regression in range estimates.
Originally we had pointer-typed AddRec there: `{%arg,+,4}<nuw><%bb6>`, which is:
```
; X32-NEXT: %i7 = phi i32* [ %arg, %bb3 ], [ %i15, %bb6 ]
; X32-NEXT: --> {%arg,+,4}<nuw><%bb6> U: full-set S: full-set Exits: ((4 * ((-4 + (-1 * %arg) + %arg1) /u 4))<nuw> + %arg) LoopDispositions: { %bb6: Computable }
```
It's constant range is 32-bit fullset, because we don't have any range knowledge for `%arg`.
Then we had a cast of it to pointer: `(zext i32 (ptrtoint i32* {%arg,+,4}<nuw><%bb6> to i32) to i64)`,
and zero-extended it to 64-bit.
So is obvious that for the old expression, constant range `[0,4294967296)` is correct.
But now we start with `zext i32 (ptrtoint i32* %arg to i32) to i64` (which is `[0,4294967296)`)
and only then we have an AddRec, and in 64 bits now.
For the AddRec, the range is `[Base + Step*max backedge-taken count, End + Step*max backedge-taken count)`.
For 32-bit AddRec, that computed to full-set that we then zero-extended,
but here it obviously computes to `[0, 4294967296 + 4*1073741823]`.
So that's it, i believe. ptrtoint is essentially a red herring here,
we should have this problem every time we sink z/s-ext into an AddRec.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89692/new/
https://reviews.llvm.org/D89692
More information about the llvm-commits
mailing list