<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 - [InstCombine] Miscompile of bitcast/zext/trunc/bitcast on vectors for big-endian targets"
href="https://bugs.llvm.org/show_bug.cgi?id=44178">44178</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[InstCombine] Miscompile of bitcast/zext/trunc/bitcast on vectors for big-endian targets
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</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>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mikael.holmen@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>In
llvm/test/Transforms/InstCombine/cast.ll
there is a test like this:
target datalayout = "E-p:64:64:64-p1:32:32:32-p2:64:64:64-p3:64:64:64-
a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-
v64:64:64-v128:128:128-n8:16:32:64"
[...]
define <3 x i32> @test60(<4 x i32> %call4) {
; CHECK-LABEL: @test60(
; CHECK-NEXT: [[P10:%.*]] = shufflevector <4 x i32> [[CALL4:%.*]],
<4 x i32> undef, <3 x i32> <i32 0, i32 1, i32 2>
; CHECK-NEXT: ret <3 x i32> [[P10]]
;
%p11 = bitcast <4 x i32> %call4 to i128
%p9 = trunc i128 %p11 to i96
%p10 = bitcast i96 %p9 to <3 x i32>
ret <3 x i32> %p10
}
If we assume the input vector is e.g. <1, 2, 3, 4> then I assume %p11
would be the (hex) value 1234, %p9 would be the 234 and %p10 would then
be the vector <2, 3, 4>.
Note that the datalayout says we're using big endian.
But the CHECK-NEXT checks that the result is made up of the elements at
index 0, 1 and 2 from the input vector, which would be <1, 2, 3>.
Similarly, test61 tests bitcast/zext/bitcast, and there I think zeroes are
added at the wrong end for big-endian targets.
The transform was added in <a href="https://reviews.llvm.org/rL103354">https://reviews.llvm.org/rL103354</a>.
The problem is in optimizeVectorResize in InstCombineCasts.cpp where we do
if (SrcTy->getNumElements() > DestTy->getNumElements()) {
// If we're shrinking the number of elements, just shuffle in the low/high
// elements from the input depending on endian and use undef as the
// second shuffle input.
V2 = UndefValue::get(SrcTy);
for (unsigned i = 0, e = DestTy->getNumElements(); i != e; ++i)
if (IC.getDataLayout().isBigEndian())
ShuffleMask.push_back(i + SrcTy->getNumElements() -
DestTy->getNumElements());
else
ShuffleMask.push_back(i);
} else {
// If we're increasing the number of elements, shuffle in all of the
// elements from InVal and fill the rest of the result elements with zeros
// from a constant zero.
V2 = Constant::getNullValue(SrcTy);
unsigned SrcElts = SrcTy->getNumElements();
for (unsigned i = 0, e = SrcElts; i != e; ++i)
ShuffleMask.push_back(i);
// The excess elements reference the first element of the zero input.
for (unsigned i = 0, e = DestTy->getNumElements()-SrcElts; i != e; ++i)
ShuffleMask.push_back(SrcElts);
}
Endianness needs to be taken into account above.
Also see discussion on llvm-dev here:
<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-November/137297.html">http://lists.llvm.org/pipermail/llvm-dev/2019-November/137297.html</a></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>