[llvm-bugs] [Bug 38842] New: Are these mask reductions optimal for arm v7+NEON ?

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38842

            Bug ID: 38842
           Summary: Are these mask reductions optimal for arm v7+NEON ?
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: llvm-bugs at lists.llvm.org

The following LLVM IR just tests if all lanes of a <N x i1> vector are true
(https://gcc.godbolt.org/z/tEd1d_):

declare i1 @llvm.experimental.vector.reduce.and.v32i1(<32 x i1>);
declare i1 @llvm.experimental.vector.reduce.and.v8i1(<8 x i1>);
declare i1 @llvm.experimental.vector.reduce.and.v4i1(<4 x i1>);
declare i1 @llvm.experimental.vector.reduce.and.v2i1(<2 x i1>);

define i1 @and64_x2(<2 x i32>) {
    %a = trunc <2 x i32> %0 to <2 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v2i1(<2 x i1> %a)
    ret i1 %b
}
define i1 @and64_x4(<4 x i16>) {
    %a = trunc <4 x i16> %0 to <4 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v4i1(<4 x i1> %a)
    ret i1 %b
}
define i1 @and64_x8(<8 x i16>) {
    %a = trunc <8 x i16> %0 to <8 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v8i1(<8 x i1> %a)
    ret i1 %b
}

define i1 @and128_x2(<2 x i64>) {
    %a = trunc <2 x i64> %0 to <2 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v2i1(<2 x i1> %a)
    ret i1 %b
}
define i1 @and128_x4(<4 x i32>) {
    %a = trunc <4 x i32> %0 to <4 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v4i1(<4 x i1> %a)
    ret i1 %b
}

define i1 @and128_x8(<8 x i8>) {
    %a = trunc <8 x i8> %0 to <8 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v8i1(<8 x i1> %a)
    ret i1 %b
}

define i1 @and256_x4(<4 x i64>) {
    %a = trunc <4 x i64> %0 to <4 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v4i1(<4 x i1> %a)
    ret i1 %b
}

define i1 @and256_x8(<8 x i32>) {
    %a = trunc <8 x i32> %0 to <8 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v8i1(<8 x i1> %a)
    ret i1 %b
}
define i1 @and256_x32(<32 x i8>) {
    %a = trunc <32 x i8> %0 to <32 x i1>
    %b = call i1 @llvm.experimental.vector.reduce.and.v32i1(<32 x i1> %a)
    ret i1 %b
}

produces this machine code:

and64_x2:
  vmov d16, r0, r1
  vdup.32 d17, d16[1]
  vand d16, d16, d17
  vmov.32 r0, d16[0]
  bx lr
and64_x4:
  vmov d16, r0, r1
  vext.16 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.16 d17, d16[1]
  vand d16, d16, d17
  vmov.u16 r0, d16[0]
  bx lr
and64_x8:
  vmov d17, r2, r3
  vmov d16, r0, r1
  vmovn.i16 d16, q8
  vext.8 d17, d16, d16, #4
  vand d16, d16, d17
  vext.8 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.8 d17, d16[1]
  vand d16, d16, d17
  vmov.u8 r0, d16[0]
  bx lr
and128_x2:
  vmov d17, r2, r3
  vmov d16, r0, r1
  vmovn.i64 d16, q8
  vdup.32 d17, d16[1]
  vand d16, d16, d17
  vmov.32 r0, d16[0]
  bx lr
and128_x4:
  vmov d17, r2, r3
  vmov d16, r0, r1
  vmovn.i32 d16, q8
  vext.16 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.16 d17, d16[1]
  vand d16, d16, d17
  vmov.u16 r0, d16[0]
  bx lr
and128_x8:
  vmov d16, r0, r1
  vext.8 d17, d16, d16, #4
  vand d16, d16, d17
  vext.8 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.8 d17, d16[1]
  vand d16, d16, d17
  vmov.u8 r0, d16[0]
  bx lr
and256_x4:
  vmov d17, r2, r3
  vmov d16, r0, r1
  mov r0, sp
  vld1.64 {d18, d19}, [r0]
  vmovn.i64 d16, q8
  vmovn.i64 d17, q9
  vuzp.16 d16, d17
  vext.16 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.16 d17, d16[1]
  vand d16, d16, d17
  vmov.u16 r0, d16[0]
  bx lr
and256_x8:
  vmov d17, r2, r3
  vmov d16, r0, r1
  mov r0, sp
  vld1.64 {d18, d19}, [r0]
  vmovn.i32 d16, q8
  vmovn.i32 d17, q9
  vuzp.8 d16, d17
  vext.8 d17, d16, d16, #4
  vand d16, d16, d17
  vext.8 d17, d16, d16, #2
  vand d16, d16, d17
  vdup.8 d17, d16[1]
  vand d16, d16, d17
  vmov.u8 r0, d16[0]
  bx lr
and256_x32:
  vmov d17, r2, r3
  vmov d16, r0, r1
  mov r0, sp
  vld1.64 {d18, d19}, [r0]
  vand q8, q8, q9
  vext.8 q9, q8, q8, #8
  vand q8, q8, q9
  vext.8 q9, q8, q8, #4
  vand q8, q8, q9
  vext.8 q9, q8, q8, #2
  vand q8, q8, q9
  vdup.8 q9, d16[1]
  vand q8, q8, q9
  vmov.u8 r0, d16[0]
  bx lr

The generated machine code for and64_x2 looks "ok" but the one generated for
and64_x4 and and64_x8 looks very long. Is this optimal ? I have similar
questions about <1 x i128>, <2 x i128> and the or and xor experimental vector
reductions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180905/bf0d61f4/attachment-0001.html>