[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