For functions with profile data, we are confident that loop sink will be optimal in sinking code.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
LGTM
lib/Transforms/Scalar/LoopSink.cpp | ||
---|---|---|
246 ↗ | (On Diff #76430) | Please add a comment here explaining why you're doing this. |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 | Can't we schedule this right after LICM? |
llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp | ||
---|---|---|
650 | 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 | 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 | 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.
Can't we schedule this right after LICM?
I think we're placing LoopSinking in a separate instance of loop pass manager - is that what we want?