According to report by @JojoR, the assertion error was hit hence we need
to have this check before the actual transformation.
Details
- Reviewers
JojoR fhahn Meinersbur craig.topper - Group Reviewers
Restricted Project - Commits
- rGc0ef83e3b930: [LSR] Check if terminating value is safe to expand before transformation
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
According to report by @JojoR, the assertion error was hit hence we need to have this check before the actual transformation.
Would it be possible to add the test case?
@JojoR May you please upload the LLVM IR with -O0 (so nothing is triggered) of what causes the assertion error to hit to here so I can try reduce the a test case out of it?
I tested again and the error is not triggered with -O0,
I reduce the test case, see attached, hope that it's helpful for you :)
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | The patch looks good to me, |
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | Sorry, may you explain more on the redundancy you see here. |
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | Looks only one expression, ignore this comment. |
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | Could you explain why the TermValueS that that is checked by Expander.isSafeToExpand before this patch is different than the TermValueS in IsToHelpFold after this patch? | |
llvm/test/Transforms/LoopStrengthReduce/lsr-term-fold-negative-testcase.ll | ||
224 ↗ | (On Diff #471034) | [nit] |
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | TermValueS calculation does not change before/after this patch. The addition here is to guard the expansion of it by checking if it is safe in the legalization of this terminating condition fold transformation. |
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
6821 | It seems like we are doing this SCEV expansion already in IsToHelpFold. Could we just return TermValueS from there rather than redoing the SCEV calculation again? |
The patch looks good to me,
but the implementation is redundant with here ?
it should merge into one ?