[PATCH] ARMEB: Vector extend operations

[Konrad Anheim]

Hi James,

I think that vld1.16 + vrev 16.8 is correct to build a 2x8 vector from a 
16bit load.

Cheers,
Conny

Am 2014-06-12 12:27, schrieb James Molloy:
> Also, as noticed by Amara:
> 
> ; CHECK-LABEL: vector_ext_2i8_to_2i64:
> ; CHECK:       vld1.16 {[[REG:d[0-9]+]]
> ; CHECK:       vmov.i64 {{q[0-9]+}}, #0xff
> ; CHECK:       vrev16.8  [[REG]], [[REG]]
> ; CHECK:       vmovl.u8  {{q[0-9]+}}, [[REG]]
> 
> ^ I think this is wrong. We shouldn't REV after a VLD1.
> 
> define void @vector_ext_2i32_to_2i64( <2 x i32>* %loadaddr, <2 x i64>*
> %storeaddr ) {
> ; CHECK-LABEL: vector_ext_2i32_to_2i64:
> ; CHECK:       vldr [[REG:d[0-9]+]]
> ; CHECK:       vrev64.32  [[REG]], [[REG]]
> ; CHECK:       vmovl.u32  {{q[0-9]+}}, [[REG]]
> 
> ^ I think this is right. We should REV after a VLDR.
> 
> These two tests are inconsistent. This implies to me that you meant to
> fix the latter (which is an actual problem), and ended up "fixing"
> correct behaviour along the way...
> 
> ... but I may be mistaken.
> 
> Cheers,
> 
> James
> 
> On 12 June 2014 11:01, James Molloy <james.molloy at arm.com> wrote:
> 
>> Hi Christian,
>> 
>> Could you please explain why this is necessary? I'm somewhat
>> confused.
>> 
>> We have canonicalised on using LD1 for vector loads, and our
>> register content is in the form "as if" loaded by an LD1. I
>> therefore do not understand why you need a VREV32 after the LD1. The
>> lane order should be correct, and all you need to do is lengthen.
>> 
>> In fact, we chose LD1 as our form **precisely because** we didn't
>> want to change the vectorizer!
>> 
>> Cheers,
>> 
>> James
>> 
>> http://reviews.llvm.org/D4043 [1]
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits [2]
> 
> 
> 
> Links:
> ------
> [1] http://reviews.llvm.org/D4043
> [2] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits