[PATCH] D103424: [IndVars] Don't forget value when inferring nowrap flags

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

@reames Just to clarify one point here, because I think there might be confusion about it. There are two possible situations:

1. SCEV already has nowrap flags, and we're just using them to prove that the IR-level operation doesn't wrap. There's definitely no need to invalidate anything in this case.
2. SCEV doesn't have nowrap flags yet, but they are inferred during the zero/sign extend operation, which tries harder to infer nowrap flags on addrecs.

In situation 2. the code already adds the nowrap flags to the addrec itself and recomputes its range. However, there may be further SCEV expressions based on that addrec, which will not get recomputed with the new nowrap information. So, the implementation //already// mutates the addrec to add the flags, the invalidation is about other expressions that might have been based on it. This doesn't make a difference on test-suite, but at least theoretically it could make a difference.

With that in mind, I'm not sure I follow your suggestion regarding an optimizable IR and RAUW operations. The concept doesn't seem to fit SCEV, in that `{1,+,1}` might have been "based on" `{0,+,1}` and might benefit from re-computation if additional information about `{0,+,1}` became known, but I don't think we would consider `{1,+,1}` a "user" of `{0,+,1}`.

I believe the actual problem here is rather that we only infer some of the nowrap information lazily -- if we didn't, then we could say with certainty that no invalidation is necessary here. However, I doubt computing it eagerly will work, there's probably considerations relating to either compile-time or SCEV construction order involved there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103424