[PATCH] D12905: [SCEV][LV] Introduce SCEV Predicates and use them to re-implement stride versioning

[hfinkel@anl.gov via llvm-commits]

hfinkel added inline comments.

================
Comment at: lib/Analysis/ScalarEvolution.cpp:9157
@@ +9156,3 @@
+
+void SCEVPredicateSet::add(const SCEVPredicate *N) {
+  if (Preds.size() > SCEVCheckThreshold || N->isAlwaysFalse()) {
----------------
sbaranga wrote:
> hfinkel wrote:
> > Can this take a threshold override, or similar, as a parameter to override SCEVCheckThreshold? We had specifically decided that loops decorated with #pragma clang vectorize(enable), which asks for vectorization but does not assert safety, would generate as many checks as necessary to enable vectorization (or be bound by some very large limit). For this case, we'll need to override the limit (or, at least, have a much larger limit). Generically, I'm skeptical of embedding the limit in SCEV at all; I think that the caller should always provide an appropriate limit for whatever happens to be its use case.
> > 
> That makes sense to me. There is currently the override in SCEV, but from your argument it looks like it should be passed in from the user.
> 
> Would that put a complexity bound on our rewriting algorithms / estimates for how expensive using these predicates can be? So far I've worked under the assumption that we would have a limited number of predicates.
> Would that put a complexity bound on our rewriting algorithms / estimates for how expensive  using these predicates can be? So far I've worked under the assumption that we would have a limited number of predicates.

I'm not too concerned about this. In cases where we want to override the "generally reasonable" limit with a large one, at least currently, this is always in response to a direct request from the user (due to a pragma or similar), and so we get to assume that the user knows what he or she is doing.



http://reviews.llvm.org/D12905