[PATCH] D27216: [SCEVExpand] do not hoist divisions by zero (PR30935)

[Sebastian Pop via Phabricator via llvm-commits]

sebpop added a comment.

In https://reviews.llvm.org/D27216#619902, @atrick wrote:

> How do you know this won't move division that used to be outside the loop (possibly multiple levels) inside the innermost loop?


At least for the easy case where the expressions are the same, and one div expression is dominating the other loop nested one,
a post processing pass like PRE should be able to find the redundancy and eliminate the inner computation.

There are still two problems:

- scev folds expressions and the expressions to be code generated do not necessarily end up to be the exact expressions as computed in the code,
- in the case of Polly's use of SCEVExpand the analyzed code belongs to a different region than the place where we need to insert the code. Polly does code versioning: it places the original loop in the then clause and starts generating code in the else clause. So no matter how hard we try to find the div expression in the code above, we won't find it, because it is probably not needed in the new code except in the expansion of the scev.


Repository:
  rL LLVM

https://reviews.llvm.org/D27216