[PATCH] D101722: [SCEV] Don't require ControlsExit for gt/lt NoWrap

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 2 09:46:52 PDT 2021


nikic created this revision.
nikic added reviewers: reames, mkazantsev, fhahn.
Herald added a subscriber: hiraditya.
nikic requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

When determining the exit count for gt/lt predicates for an AddRec with non-unit stride, we need to check whether the AddRec may overflow. NoWrap flags are used for this purpose, but currently only if `ControlsExit` is true. Among other things, this means that it must be a single-exit loop.

I believe the `ControlsExit` requirement is not necessary. To explain why, it's useful to consider the case where it **is** needed, which is for equality exit counts (https://github.com/llvm/llvm-project/blob/ec2e3e331e6d60dee77e4da83bbb192597069f15/llvm/lib/Analysis/ScalarEvolution.cpp#L9261). If we have something like `{0,+,3}<nw> == 4`, then it would be not correct to just return `4 u/ 3` as the exit count: It could be that a prior normal or abnormal exit exits before the UB branch on poison from the `<nw>` flag violation is encountered. It would be wrong to upper-bound the trip count using this exit.

The same issue doesn't apply to gt/lt predicates. If we have something like `{0,+,2}<nuw> < Len` then the loop will exit after `((1 + Len) /u 2)` iterations, if it exits through that exit. It could also exit through an earlier (normal or abnormal) exit that might prevent a poison value from reaching the branch, but that ultimately doesn't matter.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101722

Files:
  llvm/lib/Analysis/ScalarEvolution.cpp
  llvm/test/Analysis/ScalarEvolution/trip-count-non-unit-stride.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D101722.342246.patch
Type: text/x-patch
Size: 7018 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210502/88f8d08d/attachment.bin>


More information about the llvm-commits mailing list