[PATCH] D35851: [Dominators] Include infinite loops in PostDominatorTree

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

In https://reviews.llvm.org/D35851#836315, @grosser wrote:

> In https://reviews.llvm.org/D35851#836313, @grosser wrote:
>
> > Add Dani's email reply to Phab:
> >
> > >> If you generate that, you will eliminate the store a, 5 again, and you should not.
> > > 
> > > Interesting, but slightly confusing.
> >
> > This is what i get for trying to reduce an algorithm quickly.
>
>
> That's OK. It gives us an example we can work with. At least we are now on the same page. We still need to correct the example and identify the property you are interested in, but I feel we make progress. Thanks a lot again!
>
> > I'm sure i incorrectly removed some postdominance frontier checks or something.
>
> I doubt a post-dominance frontier check can be the reason. The post-dominance frontier is based on the PDT, so it should be identical for the two examples.


This reasoning is not quite correct:
FIrst, remember that with this patch, we generate a different PDT for your example and mine.  That's in fact, part of the point :)

Also remember the post dominance frontier is a combination of CFG and postdom edges.  It represents the immediately control dependent branches for the blocks (IE you can build the CDG from the RDF and reversing the mapping).
Otherwise, the DF and PDF would not need to walk the CFG.

But let's go through them:
Control dependence for these examples is definitely different.
Let's call this A:

  declare void @foo2(float* %a)
  define void @foo(i1 %cond, float* %a) {
  entry:
    br label %block1
   block1:
       store float 5.0, float* %a
       br i1 %cond, label %block2, label %block3
  
    block2:
      call void @foo2(float* %a)
      br label %block2
  
    block3:
      store float 6.0, float* %a
      ret void
  }

and this B:

  declare void @foo2(float* %a)
  define void @foo(i1 %cond, float* %a) {
  entry:
    br label %block1
   block1:
       store float 5.0, float* %a
       br i1 %cond, label %block2, label %block3
  
    block2:
      call void @foo2(float* %a)
      br i1 true, label %block2, label %block1
  
    block3:
      store float 6.0, float* %a
      ret void
  }

In A, we get:

  Printing analysis 'Post-Dominator Tree Construction' for function 'foo':
  =============================--------------------------------
  Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries.
    [1]  <<exit node>> {4294967295,4294967295} [0]
      [2] %block3 {4294967295,4294967295} [1]
      [2] %block1 {4294967295,4294967295} [1]
        [3] %entry {4294967295,4294967295} [2]
      [2] %block2 {4294967295,4294967295} [1]

In B, we get:

  Printing analysis 'Post-Dominator Tree Construction' for function 'foo':
  =============================--------------------------------
  Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries.
    [1]  <<exit node>> {4294967295,4294967295} [0]
      [2] %block3 {4294967295,4294967295} [1]
        [3] %block1 {4294967295,4294967295} [2]
          [4] %entry {4294967295,4294967295} [3]
          [4] %block2 {4294967295,4294967295} [3]

From Cytron's paper:

  A CFG node Y is control dependent on a CFG node X if both of the
  following hold:
  (1) There is a nonnull path p: X ~ Y such that Y postdominates every node
  after X on p.
  (2) The node Y does not strictly postdominate the node X
  
  LEMMA 11. Let X and Y be CFG nodes. Then Y postdominates a successor
  of X if and only if (iff ) there is a nonnull path p: X ~ Y such that Y
  postdominates every node after X on p.
  COROLLARY 1. Let X and Y be nodes in CFG. Then Y is control dependent
  on X in CFG iff X~ DF( Y) in RCFG.

So, it should be obvious that given these PDT's, the PDF is going to be different.
In one example, block 3 postdominates all the successors of block 1, in the other, it does not, so they can't have the same PDF.

IDFCalculator agrees (though note, i have not verified the output is completely correct)
But that much was obvious, you wanted to talk about the case where the PDT was the same :)

What does a 2->1 edge change in the PDF: 
It adds a control dependence on that edge.


https://reviews.llvm.org/D35851