[PATCH] ARMEB: Vector extend operations

[James Molloy]

Hi Konrad,

Thanks for the explanation. So as I understand the problem, LLVM is generating a scalar load for under-sized vectors.

I'd like to see a fuller explanation of what is going on and why in the source code and commit message. The important bits being:
  * We need to load an under-sized vector.
  * To do this we need to use a VLD1_LN to load one lane of a vector.
  * So we need to pretend that we're loading a larger vector element size than we are.
  * This means we load "as-if" VLDR, and need to perform a REV to get us back right again.

Also, the following testcase doesn't generate the best code sequence:

; 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]]

That VLDR can be a VLD1.32 dX, which means we don't need a REV. Can you please change this? I suspect this only affects extloads from 64-bit types to 128-bit types.

Cheers,

James

> -----Original Message-----
> From: Konrad Anheim [mailto:kanheim at a-bix.com]
> Sent: 12 June 2014 12:04
> To: reviews+D4043+public+b5dcb86c5807ced6 at reviews.llvm.org
> Cc: cpirker at a-bix.com; James Molloy; Amara Emerson; llvm-
> commits at cs.uiuc.edu
> Subject: Re: [PATCH] ARMEB: Vector extend operations
> 
> Hi James,
> 
> In order to load a 2x8 vector, LLVM generates a ld1.16, to load a 2x16
> vector a ld1.32 load is utilized. Therefore VREV instructions are needed
> for a correct vector representation in registers.
> 
> Cheers,
> Conny
> 
> Am 2014-06-12 12:01, schrieb James Molloy:
> > 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