This is an archive of the discontinued LLVM Phabricator instance.

Refactor replaceDominatedUsesWith to have a flag to control whether to replace uses in BB itself.
ClosedPublic

Authored by danielcdh on Sep 1 2016, 4:32 PM.

Diff Detail

Event Timeline

danielcdh updated this revision to Diff 70095.Sep 1 2016, 4:32 PM
danielcdh retitled this revision from to Refactor replaceDominatedUsesWith to have a flag to control whether to replace uses in BB itself..
danielcdh updated this object.
danielcdh added reviewers: chandlerc, davidxl.
danielcdh added a subscriber: llvm-commits.
danielcdh accepted this revision.Sep 1 2016, 4:34 PM
danielcdh added a reviewer: danielcdh.

This is also an obvious change, commit without review.

This revision is now accepted and ready to land.Sep 1 2016, 4:34 PM
danielcdh closed this revision.Sep 1 2016, 4:35 PM
chandlerc added inline comments.Sep 8 2016, 2:45 AM
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?

reverted in r280949

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

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.