[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#839798, @hfinkel wrote:

> I think that we should go ahead with this approach.


Thanks for reviewing this.

> I agree with Tobias that this has some unfortunate properties.

I agree too, fwiw!

> Nevertheless, given that we have infinite loops, it is unclear that we'd ever be able to use post-dominance to verify the lifetime intrinsics. To do so would imply that, among other things, we could use post-dominance within infinite loops as well. Given that, within the loop there are no paths to the exit node, or if you add one you must do it arbitrarily, it is not obvious to me that you can construct a definition that makes sense there.

FWIW: I believe your first sentence is correct.
If you apply Tobias's patch, the following should work but will be broken:

  declare void @foo2(float* %a)
  define void @foo(i1 %cond, float* %a) {
  entry:
    ; lifetime.start(a)
    br label %block1
  block1:
     br i1 undef, label %block2, label %block5
  block2:
     br i1 undef, label %block2, label %block3
  block3:
     ;lifetime_end(a);
     br label %block4
  block4:
     br label %block4
  block5:
     ;lifetime_end(a);
     ret void
  }

Equivalent CFG:

  A
  |  \
  B   C
        |
        D
        |
        E
  
  where C and E are also self-loops.
  
  I believe this is legal.
  Tobias's patch gives this:

[1]  <<exit node>> {4294967295,4294967295} [0]

  [2] %block5 {4294967295,4294967295} [1]
    [3] %block1 {4294967295,4294967295} [2]
      [4] %entry {4294967295,4294967295} [3]
  [2] %block4 {4294967295,4294967295} [1]
    [3] %block3 {4294967295,4294967295} [2]
      [4] %block2 {4294967295,4294967295} [3]

  This implies the lifetime end is not legally placed in block 3 (I deliberately kept it out of the loops to avoid discussion of that).
  
  It seems perfectly legal to me.
  It's reachable from entry, and i can't see a reason it's not legal to say "memory ends here".
  
  You can make block 4 whatever you want (a call that doesn't return, etc).  It still seems legal to place a memory end in block 3.  
  
  > These issues are discussed in the literature. For example, see: 
  > 
  > A new foundation for control-dependence and slicing for modern program structures
  > VP Ranganath, et al. - ESOP, 2005 
  > http://link.springer.com/content/pdf/10.1007/b107380.pdf#page=89
  > http://www.dtic.mil/get-tr-doc/pdf?AD=ADA443736
  > 
  
  I think we can also get away with separating post-dominance and control dependence if we really want.
  There is nothing that stops us from saying "Use a CDG for control dependence", and making that work however we want (or in multiple ways).


https://reviews.llvm.org/D35851