For functions with profile data, we are confident that loop sink will be optimal in sinking code.
Details
Diff Detail
- Build Status
Buildable 917 Build 917: arc lint + arc unit
Event Timeline
LGTM
lib/Transforms/Scalar/LoopSink.cpp | ||
---|---|---|
246 | Please add a comment here explaining why you're doing this. |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 ↗ | (On Diff #77293) | Can't we schedule this right after LICM? |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 ↗ | (On Diff #77293) | LICM also serves as an IR canonicalization pass that enables other optimization, so loopSinking needs to be a very late IR pass to avoid undoing LICM result too early. Otherwise the logic of loopSinking can be baked into LICM as proposed originally. |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 ↗ | (On Diff #77293) | Can we have a comment here, the PassManagerBuilder is already hard to follow, it'd be great to bake in why passes are there, and why they are where they are. |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 ↗ | (On Diff #77293) | I meant the last invocation of LICM, which is also very late (before createAlignmentFromAssumptionsPass). I don't see any loop pass in between them now. But anyway, I just wanted to make sure this placement is conscious, so if this is the case, I'm ok with it. And as Mehdi said, comments would be helpful here. |
Comments added:
r286480 | dehao | 2016-11-10 09:42:18 -0800 (Thu, 10 Nov 2016) | 2 lines
Add comments about why we put LoopSink pass at the very late stage.
Please add a comment here explaining why you're doing this.