Duncan,<br><br>I did a little more investigation, and this is what's happening:<br><br>1. DAGTypeLegalizer::ScalarizeVecRes_BinOp scalarizes a sra node of type v1i64. This function handles the node as a normal binary operand. It doesn't ensure the shift amount is the type TargetLowering::getShiftAmountTy returns, as is done in SelectionDAGBuilder::visitShift. <br>

<br>Scalarize node result 0: 0x1eedf10: v1i64 = sra 0x1eea1f0, 0x1eedc10 [ID=0]<br><br>2. The sra node gets expanded to a sra_parts node, since i64 is an illegal type.<br><br>Expand integer result: 0x1eee110: i64 = sra 0x1eea3f0, 0x1eee010 [ID=0]<br>

<br>3. When it examines the 64-bit shift amount (operand #2), it finds out it doesn't know how to expand it. mips backend doesn't mark 64-bit sra_parts as "custom", so it doesn't do anything either.<br>

<br>ExpandIntegerOperand Op #2: 0x1eeef30: i32,i32 = sra_parts 0x1eea4f0, 0x1eea7f0, 0x1eee010 [ID=0]<br><br>Do not know how to expand this operator's operand!<br><br><br>So should I fix the code which scalarizes 64-bit shifts and make sure the shift amount has the type the target expects? This is the approach taken in the attached patch (the code handles shift the same way SelectionDAGBuilder::visitShift does).<br>

<br>Alternatively, I can add code to mips backend that custom-type-legalizes 64-bit sra or sra_parts nodes. It shouldn't be hard to do so, but it makes more sense to me to make DAGTypeLegalizer emit the shift-amount node with the correct type.<br>

<br><br><div class="gmail_quote">On Mon, Dec 31, 2012 at 6:55 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Reed,<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ExpandIntegerOperand Op #2: 0xd33ed98: i32,i32 = sra_parts 0xd338628, 0xd338738,<br>
0xd331180 [ID=0]<br>
<br>
Do not know how to expand this operator's operand!<br>
UNREACHABLE executed at<br>
/home/rkotler/workspace/llvm/<u></u>lib/CodeGen/SelectionDAG/<u></u>LegalizeIntegerTypes.cpp:2451!<br>
</blockquote>
<br></div>
based on this check in DAGTypeLegalizer::<u></u>ExpandIntRes_Shift<br>
<br>
  // Next check to see if the target supports this SHL_PARTS operation or if it<br>
  // will custom expand it.<br>
  EVT NVT = TLI.getTypeToTransformTo(*DAG.<u></u>getContext(), VT);<br>
  TargetLowering::LegalizeAction Action = TLI.getOperationAction(<u></u>PartsOpc, NVT);<br>
  if ((Action == TargetLowering::Legal && TLI.isTypeLegal(NVT)) ||<br>
      Action == TargetLowering::Custom) {<br>
<br>
it looks like MIPS is claiming it knows how to custom expand an SRA_PARTS<br>
operation with an illegal type, causing an SRA_PARTS node to be used here,<br>
but in the end it doesn't custom expand it.  I think targets are allowed to<br>
do this (say custom, but in the end change their mind) so I don't thing MIPS<br>
is wrong as such.  That said, tweaking MIPS to only say Custom when it can<br>
really handle it would probably resolve the problem.  Otherwise LegalizeTypes<br>
needs to learn how to handle SRA_PARTS with illegal types.<br>
<br>
Ciao, Duncan.<div><div><br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br>