<div dir="ltr"><div><div><div><br></div>Thanks Tom.  I really appreciate your insight.<br><br></div><div>I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32.  I'm not sure then what you mean about "overriding" the ReplaceNodeResults.<br>
<br>For ReplaceNodeResults, I'm doing:<br><br> SDValue Res = LowerOperation(SDValue(N, 0), DAG);<br><br>  for (unsigned I = 0, E = Res->getNumValues(); I != E; ++I)<br>    Results.push_back(Res.getValue(I));<br></div>
<div><br></div><div>I did have to put in the following as well:<br><br>           SDValue LHS = Op.getOperand(0);<br>            SDValue RHS = Op.getOperand(1);<br>            LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS);<br>
            RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS);<br>            return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MVT::i64, LHS, RHS);<br><br></div><div>In order to get the operation to be able to be able to go forward and match the new operation with the input operands (which were still I32 and not yet type-legalized to i64).  Does this make sense to you?<br>
</div><div><br><br></div><div>Here's what I am using to generate the XXXISD::MUL32:<br><br>  if(OpVT != MVT::i64) {<br>            //Op.getNode()->dumpr();<br><br>            SDValue LHS = Op.getOperand(0);<br>            SDValue RHS = Op.getOperand(1);<br>
            LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS);<br>            RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS);<br><br>            return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MVT::i64, LHS, RHS);<br>
          }<br></div><div>Not sure if the above is correct?<br></div><div><br></div><div>It is then running into a problem with the next ADD instruction not being able to PromoteIntRes_SimpleIntBinOp, it tries to check the XXXISD::MUL32 <br>
<br>(gdb) p N->dumpr()<br>0x23ad0d0: i32 = add [ID=0] 0x23aff60, 0x23acfd0<br>  0x23aff60: i64 = <<Unknown Node #192>> [ID=-3] 0x23b0260, 0x23b0160<br>    0x23b0260: i64 = and [ID=-3] 0x23af660, 0x23b0060: i64 = Constant<4294967295> [ID=-3]<br>
      0x23af660: i64,ch = load<LD4[@i], anyext from i32> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23ac7d0: i64 = GlobalAddr\<br>ess<i32* @i> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3]<br>    0x23b0160: i64 = and [ID=-3] 0x23afc60, 0x23b0060: i64 = Constant<4294967295> [ID=-3]<br>
      0x23afc60: i64,ch = load<LD4[@j], anyext from i32> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23acbd0: i64 = GlobalAddr\<br>ess<i32* @j> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3]<br>  0x23acfd0: i32,ch = load<LD4[@k]> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23aced0: i64 = GlobalAddress<i32* @k> 0 [ID=-3\<br>
], 0x23ac9d0: i64 = undef [ID=-3]<br><br></div><div><br><br></div><div><br></div>When you say that I'll have to take care of the node elsewhere, does that mean in defining it as a proper way to lower? Like below?  I found that if I don't then put the XXXISD::MUL32 in the LowerOperation, then after it is created doing the custom change of MUL, that it just dies not knowing how to lower the machine op. I would have thought that there was a default path for any XXXISD operation?  And I didn't see other Targets generating their machine ops<br>
<br>SDValue XXXTargetLowering::<br>LowerOperation(SDValue Op, SelectionDAG &DAG) const {<br><br>  case XXXISD::MUL32:<br>    return SDValue();<br><br><br></div>Really appreciate your help and any other pointers.<br><br>
Dan<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 12:38 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan,<br>
<br>
If you set the node's action to "Custom", you should be able to<br>
interfere in the type legalisation phase (before it gets promoted to a<br>
64-bit MUL) by overriding the "ReplaceNodeResults" function.<br>
<br>
You could either expand it to a different libcall directly there, or<br>
replace it with a target-specific node (say XXXISD::MUL32) which<br>
claims to take i64 types but you really know is the 32-bit multiply.<br>
Then you'd have to take care of that node elsewhere, of course.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>