[X86] If PreprocessISelDAG reorders a load before a call, make sure w…

…e remove dead nodes from the graph

The reordering can leave at least a dead TokenFactor in the graph. This cause the linearize scheduler to fail with something like the assert seen in PR22614. This is only one of many ways we can break the linearize scheduler today so I can't say for sure that any of the other failures in that bug were caused by this issue.

This takes the heavy hammer approach of just running RemoveDeadNodes unconditionally at the end of the PreprocessISelDAG. If this turns out to be a compile time hit, we can try to refine it.

Differential Revision: https://reviews.llvm.org/D61164

llvm-svn: 359582

llvm/lib/Target/X86/X86ISelDAGToDAG.cpp

@@ -907,6 +907,11 @@ void X86DAGToDAGISel::PreprocessISelDAG() {
     ++I;
     CurDAG->DeleteNode(N);
   }
+
+  // The load+call transform above can leave some dead nodes in the graph. Make
+  // sure we remove them. Its possible some of the other transforms do to so
+  // just remove dead nodes unconditionally.
+  CurDAG->RemoveDeadNodes();
 }
 
 // Look for a redundant movzx/movsx that can occur after an 8-bit divrem.

llvm/test/CodeGen/X86/fold-call-3.ll

@@ -1,5 +1,7 @@
 ; RUN: llc < %s -mtriple=x86_64-apple-darwin | grep call | grep 560
 ; rdar://6522427
+; This command line used to crash due to dangling nodes left after PreprocessISelDAG
+; RUN: llc < %s -mtriple=x86_64-apple-darwin -pre-RA-sched=linearize
 
 	%"struct.clang::Action" = type { %"struct.clang::ActionBase" }
 	%"struct.clang::ActionBase" = type { i32 (...)** }