[PATCH] D41083: DAG: Tolerate non-MemSDNOdes for OPC_RecordMemRef

[Matt Arsenault via Phabricator via llvm-commits]

arsenm created this revision.
Herald added a subscriber: wdng.

When intrinsics are allowed to have mem operands (https://reviews.llvm.org/D40978), there
are two ways this can happen. First is an intrinsic
that is marked has having a mem operand, but is not handled
by getTgtMemIntrinsic.

      

The second way can occur even for intrinsics which do not
have a mem operand. It seems the selector table does
some kind of sorting based on the opcode, and the
mem ref recording can happen in the same scope for
intrinsics that both do and do not have mem refs.
I haven't been able to figure out exactly why this happens
(although it happens even with the matcher optimizations disabled).
I'm not sure if it's worth trying to avoid hitting this for
these nodes since I think it's still reasonable to handle
this in case getTgtMemIntrinic is not implemented.


https://reviews.llvm.org/D41083

Files:
  lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp


Index: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
===================================================================
--- lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
+++ lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
@@ -3117,7 +3117,8 @@
       continue;
     }
     case OPC_RecordMemRef:
-      MatchedMemRefs.push_back(cast<MemSDNode>(N)->getMemOperand());
+      if (auto *MN = dyn_cast<MemSDNode>(N))
+        MatchedMemRefs.push_back(MN->getMemOperand());
       continue;
 
     case OPC_CaptureGlueInput:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D41083.126415.patch
Type: text/x-patch
Size: 518 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171211/1f1dcd5a/attachment.bin>