Do you accept simple method overload in the SelectionDAG class?

     I would like to propose (another) small change to the SelectionDAG class. This change is proposed at where I added via overloading 2 new SelectionDAG::getMachineNode() methods that would allow from now on to pass four SDValue operands, something not available before. More exactly these methods are:
       MachineSDNode *SelectionDAG::getMachineNode(unsigned Opcode, const SDLoc &dl,
                                                   EVT VT,
                                                   SDValue Op1, SDValue Op2,
                                                   SDValue Op3, SDValue Op4) {
         SDVTList VTs = getVTList(VT);
         SDValue Ops = { Op1, Op2, Op3, Op4 };
         return getMachineNode(Opcode, dl, VTs, Ops);

       MachineSDNode *SelectionDAG::getMachineNode(unsigned Opcode, const SDLoc &dl,
                                                   EVT VT1, EVT VT2,
                                                   SDValue Op1, SDValue Op2,
                                                   SDValue Op3, SDValue Op4) {
         SDVTList VTs = getVTList(VT1, VT2);
         SDValue Ops = { Op1, Op2, Op3, Op4 };
         return getMachineNode(Opcode, dl, VTs, Ops);

     In case you are familiar with SelectionDAG.cpp, would you accept that I commit these 2 new SelectionDAG::getMachineNode() methods which allow 4 input operands, Op1 Op2 Op3 Op4?
    Quentin Colombet and even I more recently think that maybe adding these methods are less useful since there are already methods equivalent to them:
      > QC: Hi Alex,[...] This functionality is already covered by the array/list API of that method:
      > MachineSDNode *getMachineNode(unsigned Opcode, const SDLoc &dl, ArrayRef<EVT> ResultTys, ArrayRef<SDValue> Ops);
      > MachineSDNode *getMachineNode(unsigned Opcode, const SDLoc &dl, SDVTList VTs, ArrayRef<SDValue> Ops);
      > You can ask llvm-dev.Personally I don't think the case with 4 arguments is occurring often enough that it is worth adding this "overload". I say overload since you can already achieve that with the existing API using the lists of ops. (E.g., the implementation of the 4 arguments is just a wrapper around the list API.) Now, maybe some people are seeing this more than I do, so it may be worth [...]. Up to you!

     Please note however that I overloaded with these 2 new methods because I created several MachineSDNode with tied-to constraints, which normally require 3+1 input operands, 1 more related to the tied-to constraint. More exactly in my back end I write code like this in the SelectionDAGISel inherited class:
         SDNode *sub2 = DAG->getMachineNode(
                                             Connex::SUBV_H_TIED, // an instruction with tied-to constraints
                                             SDValue(vload1, 0), // source 1
                                             SDValue(or1, 0), // source 2
                                             SDValue(or1, 0), // tied-to constraint source (source 3) for the destination
                                             SDValue(whereeq2, 0) // glue input edge
     This SUBV_H_TIED is defined with Tablegen as an instruction with tied-to constraints like this:
             class MSA_3R_SPECIAL_DESC_BASE<string instr_asm,
                                            SDPatternOperator OpNode,
                                            RegisterOperand ROWD,
                                            RegisterOperand ROWS = ROWD,
                                            RegisterOperand ROWT = ROWD,
                                            RegisterOperand ROWS_TIED = ROWD,
                                            InstrItinClass itin = NoItinerary> ...
     I can provide more information if you think it is required.

   Thank you,