[PATCH] D58853: [SCEV] Handle case where MaxBECount is less precise than ExactBECount for OR.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

Thanks! While looking at the assertion failure, I also had a look around to see if callers of getBackedgeTakenCount & co check if the returned SCEVExpr is undef, but it seems most users do not do that. I do not have a good concrete example, where using an undef exit count is problematic, but I was wondering if it is safe in general? To me it seems problematic, e.g. if a pass expands an undef SCEVExpr.

One fishy example I could come up with are alias checks in loop-vectorize. If the trip count is undef, we will generate alias checks using undef as upper bound. Those checks could pass (-> say noalias), even though the pointers actually alias in the vector loop ( because we pick a different value for the undef trip count and now the actual trip count is different than the one used for alias checks)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58853