[llvm-bugs] [Bug 35743] New: Clang vectorizer produces incorrect code on simple test

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Dec 25 00:30:30 PST 2017


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

            Bug ID: 35743
           Summary: Clang vectorizer produces incorrect code on simple
                    test
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: max.kazantsev at azul.com
                CC: llvm-bugs at lists.llvm.org

Clang miscompiles the following function:

char foo(char c)
{
    for (int i = 1; i < 193; i++) {
          c &= (char) 1;
          c += (char) 3;
    }
    return c;
}

Run 'clang -O2 -emit-llvm -g0'

(online compiler quick link: https://godbolt.org/g/Mpfbxp)

The IR on current trunk looks like this:

define signext i8 @foo(char)(i8 signext) local_unnamed_addr #0 {
  %2 = insertelement <16 x i8> <i8 undef, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0,
i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0>, i8 %0, i32 0
  %3 = and <16 x i8> %2, <i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1,
i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1>
  %4 = icmp ne <16 x i8> %3, zeroinitializer
  %5 = shufflevector <16 x i1> %4, <16 x i1> undef, <16 x i32> <i32 8, i32 9,
i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %6 = xor <16 x i1> %4, %5
  %7 = shufflevector <16 x i1> %6, <16 x i1> undef, <16 x i32> <i32 4, i32 5,
i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %8 = xor <16 x i1> %6, %7
  %9 = shufflevector <16 x i1> %8, <16 x i1> undef, <16 x i32> <i32 2, i32 3,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %10 = xor <16 x i1> %8, %9
  %11 = shufflevector <16 x i1> %10, <16 x i1> undef, <16 x i32> <i32 1, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32
undef>
  %12 = xor <16 x i1> %10, %11
  %13 = extractelement <16 x i1> %12, i32 0
  %14 = zext i1 %13 to i8
  ret i8 %14
}

As you can see, the returned value comes from i1 which is zexted to i8. So this
IR always returns 0 or 1, while the correct answer for this test is 3 or 4
depending on oddity of variable 'c'.

The issue is reproducible on trunk and have existed since version 3.8 where the
vectorization for this test was first applied. It seems that disabling
vectorization makes the issue gone.

-- 
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/20171225/ab46afc0/attachment.html>


More information about the llvm-bugs mailing list