[PATCH] ARMEB: Vector extend operations

[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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> 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/20140612/d232336e/attachment.html>