This is in preparation for LoopSink pass which calls replaceDominatedUsesWith to update after sinking.
Details
Diff Detail
Event Timeline
include/llvm/Transforms/Utils/Local.h | ||
---|---|---|
330–334 | This was also landed without review, but I actually think this API isn't the right one. The first problem is that boolean flags to change state tend to make call sites really hard to read. All the reader sees is "false". Even if you add a comment with the name of the parameter, it doesn't help much because the parameter is pretty subtle. "IncludeSelf" is misleading as this isn't talking about instructions which use themselves, but rather users that happen to be in the same basic block. This overall seems like a confusing way to describe the operation, because dominance is no longer a very precise term. I wonder if it would make more sense to just have the client do two separate operations where it first replaces uses dominated by the basic block and then has dedicated logic to handle the uses within the basic block with clear comments explaining why this works? As one example of something that I'd want explanations around: what does it mean to replace an operand to a *phi node* in BB? Anyways, not sure if the idea above has a really bad impact on the call sites (looots of code or something), or if you see other ways to structure the API that would be more clear? |
Updated the callsite in https://reviews.llvm.org/D22778 to invoke the other API with a loop so that the API change is not required.
PTAL
Turns out the other API (dominate by edge) does not work for this purpose. I still need to use the original API (dominate by block). I've added code at the callsite to handle this. It does not look very elegant, but it's the only way I can think of that does not require API change (nor can I think of a better way to change API to make it more reasonable). Let me know if you have any suggestions.
This was also landed without review, but I actually think this API isn't the right one.
The first problem is that boolean flags to change state tend to make call sites really hard to read. All the reader sees is "false". Even if you add a comment with the name of the parameter, it doesn't help much because the parameter is pretty subtle. "IncludeSelf" is misleading as this isn't talking about instructions which use themselves, but rather users that happen to be in the same basic block.
This overall seems like a confusing way to describe the operation, because dominance is no longer a very precise term. I wonder if it would make more sense to just have the client do two separate operations where it first replaces uses dominated by the basic block and then has dedicated logic to handle the uses within the basic block with clear comments explaining why this works?
As one example of something that I'd want explanations around: what does it mean to replace an operand to a *phi node* in BB?
Anyways, not sure if the idea above has a really bad impact on the call sites (looots of code or something), or if you see other ways to structure the API that would be more clear?