[PATCH] D144861: [SCEV][IndVars][WIP] Check outer loop invariant when cononicalize comparision

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 1 00:10:22 PST 2023


nikic added a comment.

In D144861#4155833 <https://reviews.llvm.org/D144861#4155833>, @wsmoses wrote:

> If it’s possible to not revert that would be preferable as @jdoefert @vchuravy I and others have many applications that would have significant slow down if reverted.

The change also caused significant slowdowns for multiple other people, which were never addressed (e.g. https://github.com/llvm/llvm-project/issues/54191). Combined with this issue, that's enough for a revert for me.

In D144861#4160432 <https://reviews.llvm.org/D144861#4160432>, @StephenFan wrote:

> In D144861#4160179 <https://reviews.llvm.org/D144861#4160179>, @efriedma wrote:
>
>> From my analysis of the testcase, we called "getAddExpr(SCEV::FlagNUW)" while analyzing the first loop, and that broke the analysis of the second loop.  The actual simplification isn't relevant.
>
> Sorry, I don't know what you mean by "The actual simplification isn't relevant". Would you mind explaining a little more?

The getAddExpr() with NUW flag sets this flag globally, for all uses of this add. The icmp simplification itself doesn't make a difference, just the side effect that the (not globally correct) nuw flag is set.

If we don't want to revert the patch, the right fix would be to not set the NUW flag in the ControllingFiniteLoop case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144861



More information about the llvm-commits mailing list