<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Miscompilation introduced between r297481 and r297513"
href="https://bugs.llvm.org/show_bug.cgi?id=32273">32273</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Miscompilation introduced between r297481 and r297513
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: AArch64
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrew.b.adams@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18093" name="attach_18093" title=".ll that reproduces the bug">attachment 18093</a> <a href="attachment.cgi?id=18093&action=edit" title=".ll that reproduces the bug">[details]</a></span>
.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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>