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 | ||
---|---|---|
3 | 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 | ||
---|---|---|
3 | 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 | ||
---|---|---|
3 |
Using print<scalar-evolution> instead of bounds-checking would be better, as print<scalar-evolution> should be more stable. | |
36 | 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) | |
37 | does this have to be a load? |
llvm/test/Transforms/LoopRotate/pr51981-scev-problem.ll | ||
---|---|---|
37 | 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?