Details
- Reviewers
fhahn reames - Commits
- rGb0c34e0dab78: [test] Pre-commit test case for PR51981. NFC
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/test/Transforms/LoopRotate/pr51981-scev-problem.ll | ||
|---|---|---|
| 4 | Just do double check, running loop(canon-freeze) is required for the crash? Is that only so the SCEV cache is populated? | |
| llvm/test/Transforms/LoopRotate/pr51981-scev-problem.ll | ||
|---|---|---|
| 4 | Yes, that is my understanding. I tried to populate it using print<scalar-evolution> instead, or require<scalar-evolution>, but then I do not see the crash for some reason. Not quite sure why the symptom is a bit different depending on how I populate the cache. Afaict canon-freeze isn't doing any modifications to the IR (and neither should the printing). | |
| llvm/test/Transforms/LoopRotate/pr51981-scev-problem.ll | ||
|---|---|---|
| 4 |
Using print<scalar-evolution> instead of bounds-checking would be better, as print<scalar-evolution> should be more stable. | |
| 37 | it might be good to rename the blocks to make it easier to identify that there is a loop nest with 2 loops (maybe something like loop.1.header, loop.2, loop.1.latch) | |
| 38 | does this have to be a load? | |
| llvm/test/Transforms/LoopRotate/pr51981-scev-problem.ll | ||
|---|---|---|
| 38 | Haven't found anything else that still reproduce the problem (such as using an add instruction instead). | |
Just do double check, running loop(canon-freeze) is required for the crash? Is that only so the SCEV cache is populated?