Nikita Popov

Though I guess we could make this a reverse loop if there is a use case for a purely index based predicate?

> Also, we've only got a few weeks before next release branch (including the quiet holiday period with less reports), and its likely random assert regression bugs will inevitably appear...

@dtcxzyw Thanks, should be fixed by https://github.com/llvm/llvm-project/commit/e957c81750017d1ab505de8239ef993250867704.

> What about ConstantInt::getSigned - have you considered adding a ImplicitTrunc flag to that as well? Done in https://github.com/llvm/llvm-project/pull/172875.

@dtcxzyw I've added a test for this case in https://github.com/llvm/llvm-project/commit/8c93254dfcd6214e8c2e25fd9939bbb60df7e9be, and adjusted this PR to allow implicit truncation in LSR in two more places. The basic problem is that LSR...

Next crash, also in LSR... ``` target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define i32 @main(i16 %.pre.pre.i, i16 %inc18.i.i.peel) { entry: %spec.select.i.peel = add i16 %.pre.pre.i, %inc18.i.i.peel br label...

Added the test case in https://github.com/llvm/llvm-project/commit/0809a9927d67d9484e19cf3d88541bd79c5ba3b4 and adjusted the remaining `ConstantInt::get()` use in LSR...

I've submitted https://github.com/llvm/llvm-project/pull/173229 to fix that case. Also included the change in this PR for further testing.

I expect without the extra use in common.ret the sub gets sunk, and then the dominating condition is used to fold it to 0. I'm not sure where the best...

Please rebase to resolve the merge conflict and format the code using git-clang-format.