[PATCH] D54730: [DomTree] Fix order of domtree updates in MergeBlockIntoPredecessor.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 20 13:39:43 PST 2018


efriedma added a comment.

Another testcase variation (again, generate IR with Python, run opt -gvn):

  count=2000
  print "define void @f(i1 *%p) {entry:%x = load volatile i1, i1* %p br i1 %x, label %bb0, label %bb" + str(count)
  for i in xrange(count):
    print "bb{}: %x{} = load volatile i1, i1* %p br i1 %x{}, label %bbt{}, label %bbf{}".format(i,i,i,i,i)
    print "bbt{}: br label %bb{}".format(i,i+1)
    print "bbf{}: br label %bbfx{}".format(i,i)
    print "bbfx{}: br label %bb{}".format(i,i+1)
  print "bb{}: ret void}}".format(count)

This structure is helped by my patch, although not as much as my original testcase.  I'll try to dig a little more to see if I can come up with a structure to reproduce the "three times"; from the debug output, I think insert-first also limits renumbering for certain domtree structures.

Fundamentally, does this have to be an expensive operation?  It seems like there should be some way to keep a "local" operation like this from propagating across the entire tree.


Repository:
  rL LLVM

https://reviews.llvm.org/D54730





More information about the llvm-commits mailing list