LoopSink pass uses some common function in LICM. This patch refactor the LICM code to make it usable by LoopSink pass (https://reviews.llvm.org/D22778).
Details
- Reviewers
chandlerc davidxl danielcdh hfinkel - Commits
- rG92abc7e9f22b: Refactor LICM pass in preparation for LoopSink pass.
rGbc4e5bba0e88: Refactor LICM pass in preparation for LoopSink pass.
rL283134: Refactor LICM pass in preparation for LoopSink pass.
rL280425: Refactor LICM pass in preparation for LoopSink pass.
Diff Detail
Event Timeline
So, in the code review where I asked for the change, I mentioned I had some comments that should be attached to it. So that might signify that it isn't fully obvious...
And once you *ask* for a pre-commit review, it seem much more polite to see it through. Comments inbound shortly.
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
445–451 | Why this change? We try to avoid testing isa<T> just before we do a dyn_cast<T> because it duplicates work. So the other arrangement is in many ways much more common. If you're worried about the performance of this code or just trying to make it more readable what goes where, there are perhaps better patterns that can be used, but I'm not sure which to suggest without understanding the motivation. | |
460 | Any particular reason to make this change? It's not necessarily a bad change, but it seems surprising here. | |
524–525 | Please prefer early return: if (!SafetyInfo) return true; // ... return isSafeTo... |
Indeed did not notice/understand that comment, sorry about that.
And once you *ask* for a pre-commit review, it seem much more polite to see it through. Comments inbound shortly.
As noted in the other review, I misunderstood that self-approving patch is common-practice, no mean to be rude, please don't take it personally.
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
445–451 | I remember I had a reason for that... But it's a long time ago, I could not think of it now... I'm doing some more testing without hoisting it, if I still cannot find the justification, I'll revert this change. | |
460 | This is not related to this patch, just found it easier to read thus went ahead with the change. I can back it out if you want. |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | Why is this not returning a conservative answer? |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | SafetyInfo will be non-null for LICM, and will be nullptr for LoopSink, which is always safe. Basically, I used this pointer to distinguish between LICM and LoopSink usage to reuse the code as much as possible without introduce new parameter to the API. Let me know if you think that is confusing:
|
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | This is a good question, it may just mean that "SafetyInfo" needs a better name or this needs a comment to explain why this is correct. Alternatively, we could require that SafetyInfo is always provided. |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | (sorry, crossing replies) I think making it more clear that the difference is between *hoisting* and *sinking* would really help. That explains the reason you don't need to call isSafeToExecuteUnconditionally at all. |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | Do you mean that I add a comment to the early return? |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | I agree. This makes sense, but please add a comment here, and also a comment in LoopUtils.h for each relevant interface explaining that passing nullptr for SafetyInfo is for sinking. |
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
519 | Yes. The comment before the early return should specifically point out that for sinking we don't need to check isSafeToExecuteUnconditionally. |
Commends updated to LICM.cpp. This change does not affect other functions in LoopUtils.h. But when I move canSinkOrHoistInst to LoopUtils.h in the next patch, I'll have the updated comment there too.
LGTM
lib/Transforms/Scalar/LICM.cpp | ||
---|---|---|
441 | sinking instruction from should be "sinking instructions from" or "sinking this instruction from" |
Thanks for the reviews!
As this was original proposed by Chandler, I'll hold this until later today and see if he has more comment.
Hal, it would be great if you can also shed some lights on https://reviews.llvm.org/D22778 (I'll do a quick rebase now). Thanks!
sinking instruction from should be "sinking instructions from" or "sinking this instruction from"