[llvm-commits] [llvm] r170532 - in /llvm/trunk: include/llvm/Target/TargetLowering.h lib/CodeGen/SelectionDAG/TargetLowering.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/ARM/ARMISelLowering.h lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h

[Akira Hatanaka]

Duncan,

I did a little more investigation, and this is what's happening:

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.

Scalarize node result 0: 0x1eedf10: v1i64 = sra 0x1eea1f0, 0x1eedc10 [ID=0]

2. The sra node gets expanded to a sra_parts node, since i64 is an illegal
type.

Expand integer result: 0x1eee110: i64 = sra 0x1eea3f0, 0x1eee010 [ID=0]

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.

ExpandIntegerOperand Op #2: 0x1eeef30: i32,i32 = sra_parts 0x1eea4f0,
0x1eea7f0, 0x1eee010 [ID=0]

Do not know how to expand this operator's operand!


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).

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.


On Mon, Dec 31, 2012 at 6:55 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Reed,
>
>
>  ExpandIntegerOperand Op #2: 0xd33ed98: i32,i32 = sra_parts 0xd338628,
>> 0xd338738,
>> 0xd331180 [ID=0]
>>
>> Do not know how to expand this operator's operand!
>> UNREACHABLE executed at
>> /home/rkotler/workspace/llvm/**lib/CodeGen/SelectionDAG/**
>> LegalizeIntegerTypes.cpp:2451!
>>
>
> based on this check in DAGTypeLegalizer::**ExpandIntRes_Shift
>
>   // Next check to see if the target supports this SHL_PARTS operation or
> if it
>   // will custom expand it.
>   EVT NVT = TLI.getTypeToTransformTo(*DAG.**getContext(), VT);
>   TargetLowering::LegalizeAction Action = TLI.getOperationAction(**PartsOpc,
> NVT);
>   if ((Action == TargetLowering::Legal && TLI.isTypeLegal(NVT)) ||
>       Action == TargetLowering::Custom) {
>
> it looks like MIPS is claiming it knows how to custom expand an SRA_PARTS
> operation with an illegal type, causing an SRA_PARTS node to be used here,
> but in the end it doesn't custom expand it.  I think targets are allowed to
> do this (say custom, but in the end change their mind) so I don't thing
> MIPS
> is wrong as such.  That said, tweaking MIPS to only say Custom when it can
> really handle it would probably resolve the problem.  Otherwise
> LegalizeTypes
> needs to learn how to handle SRA_PARTS with illegal types.
>
> Ciao, Duncan.
>
> ______________________________**_________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvm-commits<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130108/4b3b7122/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shiftparts1.patch
Type: application/octet-stream
Size: 2821 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130108/4b3b7122/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shiftparts1.ll
Type: application/octet-stream
Size: 723 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130108/4b3b7122/attachment-0001.obj>