[llvm-bugs] [Bug 32273] New: Miscompilation introduced between r297481 and r297513

[via llvm-bugs]

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

            Bug ID: 32273
           Summary: Miscompilation introduced between r297481 and r297513
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew.b.adams at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18093
  --> https://bugs.llvm.org/attachment.cgi?id=18093&action=edit
.ll that reproduces the bug

The .ll in the attachment, when compiled like so:

llc  -march=aarch64 -O3 -filetype=asm -o good.s test.ll

produces different outputs at r297481 and r297513. The older commit is the
correct one.

It's a boundary condition test, which pads the sides of an image with 42s. It's
a bit weird in that it uses 32-element vectors, which is not a native vector
width on arm. The error does not show up with narrower vectors.

The relevant piece of .ll is:

  %820 = icmp sge i64 %indvars.iv, %368
  %821 = insertelement <32 x i1> undef, i1 %820, i32 0
  %822 = shufflevector <32 x i1> %821, <32 x i1> undef, <32 x i32>
zeroinitializer
...
  %1019 = icmp sle <32 x i32> %362, %825
  %1020 = icmp slt <32 x i32> %825, %363
  %1021 = or <32 x i1> %1019, %822
  %1022 = or <32 x i1> %1021, %1020
  %1023 = select <32 x i1> %1022, <32 x i8> <i8 42, i8 42, i8 42, i8 42, i8 42,
i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8
42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8 42, i8
42, i8 42, i8 42, i8 42, i8 42>, <32 x i8> %1018
...

Looking at the asm diffs (which are small), the <32 x i1> conditions are
lowered to <32 x i8> vectors in v28 and v31 (%1022), and then the entries are
normalized to either 0 or 255 by a shift left of 7 bits followed by a signed
shift right of 7 bits. The mask is then used in the select instruction to
produce %1023. This normalization is necessary because the select lowers to
bsl, which is a bitwise select. This normalization seems to be missing in the
newer rev. 

I think perhaps llvm has decided it isn't necessary, because many of the things
that go into making v28 and v31 have already been normalized in this way. But
not all of them. I think v9 and v11 (%822?) come from w22 (%820?), which is
last touched by a cset, so it's either 0 or 1, not 0 or 255.

This makes sense given the bad output I'm seeing. I think w22 is the condition
which checks whether we're out-of-bounds in the y axis. The error in the output
I'm seeing is that pixels that are out of bounds are treated as if they are
in-bounds. So w22 being true is not having the desired effect, probably because
it's 1 instead of 255.

-- 
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/20170315/3e371eaf/attachment-0001.html>