This is an archive of the discontinued LLVM Phabricator instance.

[LSR] Make sure that Factor fits into Base type
ClosedPublic

Authored by danilaml on Aug 26 2021, 11:03 AM.

Diff Detail

Event Timeline

danilaml created this revision.Aug 26 2021, 11:03 AM
danilaml requested review of this revision.Aug 26 2021, 11:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2021, 11:03 AM
danilaml added inline comments.Aug 26 2021, 11:19 AM
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
3974

Avoids truncation/overflow here.

anna added a subscriber: anna.Aug 27 2021, 1:04 PM
anna added inline comments.
llvm/test/Transforms/LoopStrengthReduce/pr42770.ll
1

You could add REQUIRES:assert here along with XFAIL to precommit the test.

danilaml updated this revision to Diff 369192.Aug 27 2021, 2:39 PM

Add missing REQUIRES: asserts

danilaml updated this revision to Diff 369459.Aug 30 2021, 8:53 AM

Addressed Anna's suggestions

danilaml marked an inline comment as done.Aug 30 2021, 8:53 AM
qcolombet added inline comments.Sep 16 2021, 5:13 PM
llvm/test/Transforms/LoopStrengthReduce/pr42770.ll
1

Could you check that we generate something sensible here as opposed to just no-crash?

1

Could you set a more descriptive file name than a pr number?

E.g., incompatible IV type and add the PR number in the comment of the test.

danilaml updated this revision to Diff 373204.Sep 17 2021, 6:22 AM

Addressed Quentin's comments

danilaml marked 2 inline comments as done.Sep 17 2021, 6:25 AM
danilaml added inline comments.
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.

qcolombet accepted this revision.Sep 17 2021, 9:21 AM

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

This revision is now accepted and ready to land.Sep 17 2021, 9:21 AM
danilaml updated this revision to Diff 373378.Sep 17 2021, 5:12 PM
danilaml marked an inline comment as done.

Add more comments to the test

danilaml added inline comments.Sep 17 2021, 5:21 PM
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.

This revision was landed with ongoing or failed builds.Sep 21 2021, 10:51 AM
This revision was automatically updated to reflect the committed changes.