llvm dev - Dec 2014 - [LLVMdev] AArch64 codegen question

Hi AArch64 experts -

I'm working on a DAGCombiner patch, and it causes a change in an existing
regression test.

We're generating this:
   ext    v0.16b, v1.16b, v1.16b, #8

Rather than this:
   mov    d0, v1.d[1]

Are those logically equivalent? Is one form preferred over the other?

This is the IR test case in /test/CodeGen/AArch64/neon-scalar-copy.ll:

define <1 x i64> @test_vector_copy_dup_dv2D(<1 x i64> %a, <2 x
i64> %c) {
  ; CHECK-LABEL: test_vector_copy_dup_dv2D
  ; CHECK: {{dup|mov}} {{d[0-9]+}}, {{v[0-9]+}}.d[1]
  %vget_lane = extractelement <2 x i64> %c, i32 1
  %vset_lane = insertelement <1 x i64> undef, i64 %vget_lane, i32 0
  ret <1 x i64> %vset_lane
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/908f0b59/attachment.html>

Hi Sanjay,

On 10 December 2014 at 19:47, Sanjay Patel <spatel at rotateright.com>
wrote:
> We're generating this:
>    ext    v0.16b, v1.16b, v1.16b, #8
>
> Rather than this:
>    mov    d0, v1.d[1]
>
> Are those logically equivalent? Is one form preferred over the other?
They're certainly semantically equivalent, and I'd expect the
performance to be the same too. I wouldn't worry about a change like
that if it was me. What's the DAG change that causes it?

Cheers.

Tim.

Hi Tim -

Thanks for the answer!

We have this sequence:
        0x7f90c103d130: v2i64,ch = CopyFromReg 0x7f90c0c16e20,
0x7f90c103d020 [ORD=1] [ID=-3]
        0x7f90c103d350: i64 = Constant<1> [ID=-3]
     0x7f90c103d460: i64 = extract_vector_elt 0x7f90c103d130,
0x7f90c103d350 [ORD=2] [ID=-3]
    0x7f90c103fa00: v1i64 = BUILD_VECTOR 0x7f90c103d460 [ORD=3] [ID=-3]

That currently gets transformed to:
        0x7f90c103d130: v2i64,ch = CopyFromReg 0x7f90c0c16e20,
0x7f90c103d020 [ORD=1] [ID=4]
        0x7f90c103d350: i64 = Constant<1> [ID=2]
      0x7f90c103d460: i64 = extract_vector_elt 0x7f90c103d130,
0x7f90c103d350 [ORD=2] [ID=5]
    0x7f90c103dce0: v1i64 = scalar_to_vector 0x7f90c103d460 [ORD=3]

My patch is looking for that ( BUILD_VECTOR ( extract_vector_elt (...) )
pattern and changing it to:
       0x7fe67a039130: v2i64,ch = CopyFromReg 0x7fe679511410,
0x7fe67a039020 [ORD=1] [ID=4]
      0x7fe67a039350: i64 = Constant<1> [ID=2]
    0x7fe67a039570: v1i64 = extract_subvector 0x7fe67a039130,
0x7fe67a039350 [ORD=3] [ID=5]

...Now that I'm seeing this, I should probably just avoid firing on a
build_vector of length 1. :)


On Wed, Dec 10, 2014 at 9:09 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> Hi Sanjay,
>
> On 10 December 2014 at 19:47, Sanjay Patel <spatel at
rotateright.com> wrote:
> > We're generating this:
> >    ext    v0.16b, v1.16b, v1.16b, #8
> >
> > Rather than this:
> >    mov    d0, v1.d[1]
> >
> > Are those logically equivalent? Is one form preferred over the other?
>
> They're certainly semantically equivalent, and I'd expect the
> performance to be the same too. I wouldn't worry about a change like
> that if it was me. What's the DAG change that causes it?
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/64b57013/attachment.html>