[PATCH] D151799: [ConstraintElim] Try to use first cmp to prove second cmp for ANDs.

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

Are you planning to implement the de Morgan conjugate for or as well? I don't like having asymmetric handling for and/or.



================
Comment at: llvm/lib/Transforms/Scalar/ConstraintElimination.cpp:732
+      WorkList.push_back(FactOrCheck::getCheck(DT.getNode(Successor), And));
+  }
 
----------------
Given that this is a check, why is this only handled for branch operands and only if we can add a successor? Shouldn't this be handled the same as icmps in the loop above?


================
Comment at: llvm/lib/Transforms/Scalar/ConstraintElimination.cpp:1053
+        return DTN->getDFSNumIn() >= CB.NumIn &&
+               DTN->getDFSNumOut() <= CB.NumOut;
+      });
----------------
Okay, so I guess this is the bit that makes use of the branch -- but I don't really get what this has to do with the and.

We're already going to add both and operands as facts for the branch. The only situation where I would expect this to make a difference if an icmp gets defined outside the branch and used inside the branch, and also just happens to be part of a dominating and.

But this "defined in a different block" situation is a generic problem for constraint elimination, it seems odd to handle it for this specific special case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151799/new/

https://reviews.llvm.org/D151799