[PATCH] D56719: [DAGCombine] Enable more pre-indexed stores

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 17 14:08:40 PST 2019


efriedma added a comment.

I just did a very brief experiment, and just checking `if (Val == BasePtr || Val == Ptr || Ptr->isPredecessorOf(Val.getNode()))` seems to do the right thing without any additional checks.  Is all this extra code really necessary?



================
Comment at: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:12666
+    // - and Val is not in the use-def chain between BasePtr and the store,
+    //   this prevents Val from being dependent of the pre-inc'd address.
+    if (BasePtr.getNode()->isPredecessorOf(Val.getNode())) {
----------------
samparker wrote:
> efriedma wrote:
> > I think this could still use a bit more clarification...
> > 
> > There are two different uses of ReplaceAllUsesOfValueWith which could cause a cycle related to stored value: the replacement of Ptr with the pre-indexed result, and the rewritten arithmetic relative to BasePtr in OtherUses.  Are you trying to prevent both those cycles?  Could we be more aggressive if we separated those checks?
> So yes, I am trying to make sure that Ptr can be replaced legally and I have assumed that by allowing the last scheduled user to be a pre-indexed store, we don't have to worry about OtherUses. Though I am now confused after re-reading statement (3) from above which appears to directly contradict my thoughts.
There's a hasPredecessorHelper call later; I think that handles cases like (3).


================
Comment at: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:12669
+      for (auto *U : BasePtr.getNode()->uses()) {
+        if (Val.getNode() == U)
+          return false;
----------------
samparker wrote:
> efriedma wrote:
> > The equality check here seems suspect; what if Val is a use of one of the direct users of BasePtr?
> Hmm. Would it be valid to create an ADD/SUB node and check whether it becomes a predecessor of Val...?
ADD/SUB of what, exactly?

More generally, we want to avoid performing predecessor checking more than once, since it's expensive.


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

https://reviews.llvm.org/D56719





More information about the llvm-commits mailing list