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

[Sanjoy Das via Phabricator via llvm-commits]

sanjoy added a comment.

In D58853#1415902 <https://reviews.llvm.org/D58853#1415902>, @fhahn wrote:

> 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)


I think you're right -- generating safety checks is unsound if there is an `undef` in the trip count expression.  This will be solved once we use `poison` as the standard "deferred UB" construct.  The software engineering problem here has been that it is very difficult to trigger this sort of corner cases using `undef` via well defined C/C++ programs, so we as a community haven't had an urgent incentive to fix these corner cases.

For now I think a good workaround would be to:

- Not simplify `undef` in SCEV expressions
- Avoid doing things that would require us to expand SCEV expressions with `undef` in them


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58853