[PATCH] D37175: Fix PR/33305. caused by trying to simplify expressions in phi of ops that should have no leaders.

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

Unfortunately, i can prove we have to give up rather than try to constant fold in this case.

Given:

  for.body.i:
     %tmp1 = phi i1 [ true, %entry ], [ false, %cond.end.i ]
     %f.08.i = phi i32 [ 0, %entry ], [ %inc.i, %cond.end.i ]
     %mul.i = select i1 %cmp1.i, i32 %f.08.i, i32 0
     br i1 %tmp1, label %cond.end.i, label %cond.true.i
  
   cond.true.i:
     ;; Ensure we don't replace this divide with a phi of ops that merges the wrong loop iteration value
     %div.i = udiv i32 %mul.i, %f.08.i
     br label %cond.end.i

And trying to perform phi of ops on the udiv,  the expression that normally can't be found is udiv i32 %mul.i, 0, even though that expression is 0.

(%mul.i can't exist in the entry predecessor).

If we don't fail phi of ops in that case, we may get the wrong answer.

So i'm going to rework this slightly (I've also moved to recursive DFS, and not try to check operands we translated).

I'm going to also test the cost of doing recursive translation on all the operands to see which turn out constant or have leaders (which is safe, but O(N) in the depth of the expression tree)

We can cache the translations as they can't change until the related operands change, and see how expensive it is in practice.

That will actually catch *more* cases than we do now.


https://reviews.llvm.org/D37175