This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Extended Dominance analysis with a function to find the nearest common dominator of two given blocks.
ClosedPublic

Authored by dfki-mako on Mar 3 2020, 1:42 AM.

Details

Summary

The Dominance analysis currently misses a utility function to find the nearest common dominator of two given blocks. This is required for a huge variety of different control-flow analyses and transformations. This commit adds this function and moves the getNode function from DominanceInfo to DominanceInfoBase, as it also works for post dominators.

Diff Detail

Event Timeline

dfki-mako created this revision.Mar 3 2020, 1:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2020, 1:42 AM
herhut added a subscriber: herhut.Mar 3 2020, 2:16 AM
herhut added inline comments.
mlir/lib/Analysis/Dominance.cpp
47

What about the case where one block is in an ancestor region of the other block. Something like

bb0^:
  "some.op"() {
    bb1^:
      // some code
  }
dfki-mako updated this revision to Diff 247830.Mar 3 2020, 2:18 AM
dfki-mako removed a subscriber: herhut.

Fixed invalid indentation that was caused by automatic post-commit formatters.

@herhut Regarding your example that one block is in a nested region of the second block: you are right that you will not get the nearest common dominator in this case. In order to add support for these cases, we will have to check whether one region is nested into the other one. May we use the 'isProperAncestor' function to check whether a is nested into b or vice versa?

rriddle requested changes to this revision.Mar 3 2020, 9:16 AM

Thanks for the patch! I added a few comments.

mlir/lib/Analysis/Dominance.cpp
31

Keep the position of methods relative to the position in the class declaration, i.e. this should be below recalculate.

55

It isn't clear to me that this is correct. What happens if the region containing a is a common ancestor of b? Seems like this should be doing something similar to properlyDominates, i.e. traversing the ancestors of b looking for the region containing a.

This revision now requires changes to proceed.Mar 3 2020, 9:16 AM
dfki-mako updated this revision to Diff 248695.Mar 6 2020, 4:10 AM

Added support for nested regions.
Added test cases for dominance information.

dfki-mako updated this revision to Diff 249045.Mar 9 2020, 2:23 AM

Fixed invalid comment in TestDominance.cpp.

herhut added inline comments.Mar 9 2020, 5:05 AM
mlir/lib/Analysis/Dominance.cpp
97

not able -> not be able

159

a not a => not a

162

You did not introduce this. Still, I do not get the post-dominates here. If a and b are both in subregions, like

top {
  op1 {
    a^:
  }
  op2 {
    b^:
  }
}

then the above code will not find a region in the ancestry of b that is also the region of a. Still, a does not post-dominate b.

mlir/test/lib/Transforms/TestDominance.cpp
50

The output of this is misleading to read. The -> reads like the lhs dominates the rhs. Something like Nearest(0, 1) = 2 would be easier.

dfki-mako updated this revision to Diff 249120.Mar 9 2020, 8:49 AM
dfki-mako marked 3 inline comments as done.

Fixed missing "be" in comment and changed output to "Nearest(x, y) = z".

rriddle added inline comments.Mar 9 2020, 10:58 AM
mlir/lib/Analysis/Dominance.cpp
162

Nested dominance has a lot of trickyness. We generally model dominance here as being able to flow-in, but not flow-out. So in the above, a^ can't dominate anything defined above its region inside of op1. That being said, different users want different things so we could likely expand the API surface area to handle the different cases.

herhut added inline comments.Mar 12 2020, 7:23 AM
mlir/lib/Analysis/Dominance.cpp
162

@rriddle I was more wondering about the case of post-dominance here. In the current implementation, a post-dominates b if I read the code right. That seems wrong to me.

a also does not dominate b.

being able to flow-in, but not flow-out

I did not understand that comment.

uenoku added a subscriber: uenoku.Mar 12 2020, 10:32 AM
herhut accepted this revision.Mar 26 2020, 3:39 AM

As this does not change the semantics of what is currently implemented, I am fine with this to land.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 27 2020, 7:04 AM
This revision was automatically updated to reflect the committed changes.
dfki-mako marked 4 inline comments as done.