[llvm] r262397 - DAGCombiner: Turn truncate of a bitcasted vector to an extract

[Mikael Holmén via llvm-commits]

Hi,

On 03/04/2016 02:33 AM, Matt Arsenault wrote:
>
>> On Mar 3, 2016, at 00:27, Mikael Holmén via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>
>> Hi Matt,
>>
>> What about Big Endian targets? Shouldn't we extract the highest vector element instead of element 0 then?
>>
>> Regards,
>> Mikael
>
> I don’t know how vectors types work on big endian targets

Me neither. :D

But one case I've seen for my big-endian out-of-tree target is that we have:

@g_cm_s = addrspace(21) global %rec802 { [4 x i16] [i16 111, i16 112, 
i16 113, i16 114] }

and then:

   %1 = load <4 x i16>, <4 x i16> addrspace(21)* bitcast (%rec802 
addrspace(21)* @g_cm_s to <4 x i16> addrspace(21)*)
   %2 = bitcast <4 x i16> %1 to i64
   %3 = trunc i64 %2 to i16
   %_tmp7 = icmp eq i16 %3, 114

Without the new optimization in visitTRUNCATE this code works well for 
me. The result of the trunc is 114 as expected, but with your change we 
get 111.

So I've changed

+
+      // We need to consider endianness when deciding which vector
+      // element to extract.
+      unsigned ElmtIdx =
+        DAG.getDataLayout().isBigEndian()
+        ? SrcVT.getVectorNumElements() - 1
+        : 0;
        return DAG.getNode(ISD::EXTRACT_VECTOR_ELT, SL, VT,
-                         VecSrc, DAG.getConstant(0, SL, IdxVT));
+                         VecSrc, DAG.getConstant(ElmtIdx, SL, IdxVT));

locally to get my test to pass.

I've no idea if there are any big-endian in-tree targets that has 
vectors where this can be an issue.

/Mikael

>
> -Matt
>