Putting "tied-to" constraints on virtual registers in SelectionDAGISel's Select() method

Hello.
     I expand an instruction to a sequence of MachineSDNodes at instruction selection, in the Select() method of the SelectionDAGISel class.
     For efficiency, in order to generate fewer instructions, I would like to assign twice to the same physical register - but since I don't want to "mess" with the register allocator, I am using only virtual registers.
     However, if I write in my C++ code 2 getCopyToReg() calls to the same virtual register - this gives me the following error: "getVRegDef assumes a single definition or no definition" later, after instruction selection.
     Therefore, I try to use 2 virtual registers for the same physical register. I know in TablGen instruction specs we can give "tied-to" constraints on virtual registers of the form:
       string Constraints = "$regInput = $regOutput";

     Can we put such "tied-to" constraints programatically also at instruction selection, in the Select() method of the SelectionDAGISel class?

   Thank you,
     Alex

You have to specify "Constraints" in TableGen: it's a property of the instruction. That said, because it's a property of the instruction, it still applies to nodes selected using C++ code in Select().

-Eli

Hello.
     I come back to ask about the tied-to constraints of MachineInstr, specifiable in TableGen through properties like:
         string Constraints = "$wd = $ws";

     Is there any good reference (academic paper) on tied-to constraints? For me they look very similar to the constraints in register coalescing - see e.g. page 3, slide 11 of https://www.cs.cmu.edu/afs/cs/academic/class/15745-s16/www/lectures/L23-Register-Coalescing.pdf.

     I looked a bit in the LLVM code - tied-to constraints are taken into consideration in the allocator, but also in the modules RegisterCoalescer.cpp, TwoAddressInstructionPass.cpp, etc.
     I will try one of these days to see if using many such tied-to constraints in a rather small program can result in severely suboptimal allocation.

   Thank you,
     Alex