Fixes pr42770
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
|---|---|---|
| 3974 | Avoids truncation/overflow here. | |
| llvm/test/Transforms/LoopStrengthReduce/pr42770.ll | ||
|---|---|---|
| 1 | You could add REQUIRES:assert here along with XFAIL to precommit the test. | |
| llvm/test/Transforms/LoopStrengthReduce/pr42770.ll | ||
|---|---|---|
| 1 | I've added some checks although I don't really like the idea of checking the generated IR past the labels (and it looks like most of the lit tests in this folder don't do it either), since I don't want to depend on the actual optimizations made by LSR. Just that it won't try to use out-of-range scaling factor for one of the IVs. | |
One last comment, otherwise LGTM.
| llvm/test/Transforms/LoopStrengthReduce/scaling-factor-incompat-type.ll | ||
|---|---|---|
| 1–3 | Could you add a more descriptive comment on what this is testing and how? (I.e., the characteristics of the test and what we should be observing when the optimization does the right thing.) | |
| llvm/test/Transforms/LoopStrengthReduce/scaling-factor-incompat-type.ll | ||
|---|---|---|
| 1–3 | It's more about preventing the wrong logic (that quickly leads to assert), when expecting anything out of the optimization. In the test case Factor == 2^32 truncated to i16 would be 0, which meant that F.BaseRegs were zeroed out as well. const SCEV *FactorS = SE.getConstant(IntTy, Factor);
// Check that multiplying with each base register doesn't overflow.
for (size_t i = 0, e = F.BaseRegs.size(); i != e; ++i) {
F.BaseRegs[i] = SE.getMulExpr(F.BaseRegs[i], FactorS)This then quickly asserted in InsertFormula. Anyway, hopefully if anyone needs more context, they can look up this review or bug report. | |
Avoids truncation/overflow here.