[PATCH] ARMEB: Vector extend operations

James Molloy james at jamesmolloy.co.uk
Thu Jun 12 03:27:24 PDT 2014

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.



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>

More information about the llvm-commits mailing list