If a loop contains several BBs, peeling produces code in which jump
targets point to original loop blocks rather than cloned BBs. This
patch uses the same way as loop unrolling to remap cloned blocks.
Details
Diff Detail
- Build Status
Buildable 5003 Build 5003: arc lint + arc unit
Event Timeline
lib/Transforms/Utils/LoopUnrollPeel.cpp | ||
---|---|---|
419 | Something here is wrong. There's already a call to remapInstructionsInBlocks in line 443 (original) that does exactly this, so everything ought to be updated correctly. If it isn't, then something's going wrong between here and there, and I'm not sure what it is. |
lib/Transforms/Utils/LoopUnrollPeel.cpp | ||
---|---|---|
419 | Indeed, you are right. But the remapping is made too late, it must be done prior to dominator tree calculation, which in turn must be done prior to call to SplitBlock. |
LGTM, but please fix the test before committing.
lib/Transforms/Utils/LoopUnrollPeel.cpp | ||
---|---|---|
419 | Ok, this makes more sense. So what happened here isn't that we generated bad branches, it's that we produced a malformed dominator tree? | |
test/Transforms/LoopUnroll/peel-loop.ll | ||
99 | Please make the test actually test its output (in particular, that we actually peeled the loop). |
Thank you for review.
lib/Transforms/Utils/LoopUnrollPeel.cpp | ||
---|---|---|
419 | Yes, the problem is only malformed dominator tree. It was found in self builds with expensive checks enabled. | |
test/Transforms/LoopUnroll/peel-loop.ll | ||
99 | Done, but I had to move the test into separate file, as with options of peel-loop.ll the code changed too substantially. |
Something here is wrong. There's already a call to remapInstructionsInBlocks in line 443 (original) that does exactly this, so everything ought to be updated correctly. If it isn't, then something's going wrong between here and there, and I'm not sure what it is.