[llvm-dev] getMachineNode() returns the same SDNode over and over again due to CSE in the instruction selection phase

Alex Susu via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 11 11:50:01 PST 2017

     This is less a question but more a solution to a problem I encountered yesterday. 
Still, if you have any comments please don't hesitate to give feedback.

     In my research processor back end, in [Target]ISelDAGToDAG.cpp I give in method Select():
       SDNode *vloadSpecial = CurDAG->getMachineNode(
                                              TYPE_VECTOR, // problems with CSE
                                              //CurDAG->getVTList(TYPE_VECTOR, MVT::Glue),
                                                               // NO problems with CSE
                                              CurDAG->getEntryNode() // We add a chain edge
      But this getMachineNode() call returns the same SDNode over and over again in the 
same basic block due to CSE in the instruction selection phase, since the machine node 
doesn't take any actual inputs.
     Therefore, I add MVT::Glue to the return types to avoid that llc performs CSE on 
these nodes. See why this is so at 
http://llvm.org/docs/doxygen/html/SelectionDAG_8cpp_source.html#l06206 . More exactly:
         06208   bool DoCSE = VTs.VTs[VTs.NumVTs-1] != MVT::Glue;
         06214   if (DoCSE) {
         06215     FoldingSetNodeID ID;
         06216     AddNodeIDNode(ID, ~Opcode, VTs, OpsArray);
         06217     IP = nullptr;
         06218     if (SDNode *E = FindNodeOrInsertPos(ID, DL.getDebugLoc(), IP)) {
         06219       return cast<MachineSDNode>(UpdadeSDLocOnMergedSDNode(E, DL));
         06220     }
         06221   }
     I simply added MVT::Glue to the MachineNode, without bothering to use this edge with 
any successor node and me specifying such output in TableGen for VLOAD_D_WO_IMM - I used 
CurDAG->getVTList(TYPE_VECTOR, MVT::Glue) instead of TYPE_VECTOR in the code above.

      Note that allowing the instruction-selection phase to do CSE actually results in 
incorrect machine code, with fewer VLOAD_D_WO_IMM instructions than required.

     This code is correct for a few tests I ran, but I wonder if I am missing anything.

   Best regards,

More information about the llvm-dev mailing list