[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