<html>
<head>
<base href="https://llvm.org/bugs/" />
</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][AArch64] Missed bswap opportunities for i16"
href="https://llvm.org/bugs/show_bug.cgi?id=27824">27824</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[InstCombine][AArch64] Missed bswap opportunities for i16
</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>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mcrosier@codeaurora.org
</td>
</tr>
<tr>
<th>CC</th>
<td>david.majnemer@gmail.com, llvm-bugs@lists.llvm.org, t.p.northover@gmail.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Given this test case:
unsigned short test(unsigned short a) {
unsigned short b = (a & 0xff00) >> 8;
unsigned short c = (a & 0x00ff) << 8;
return b | c;
}
When targeting x86 (which considers i16 as legal type) the above will be
converted into a bswap.
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: nounwind readnone uwtable
define zeroext i16 @test(i16 zeroext %a) {
entry:
%or = tail call i16 @llvm.bswap.i16(i16 %a)
ret i16 %or
}
Just before the bswap is matched the IR looks like this:
define zeroext i16 @test(i16 zeroext %a) {
entry:
%shr11 = lshr i16 %a, 8
%and3 = shl i16 %a, 8
%or = or i16 %shr11, %and3
ret i16 %or
}
However, on AArch64 (which doesn't considers i16 as a legal type) we are unable
to convert the code to a bswap.
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux-gnu"
define i16 @test(i16 %a) {
entry:
%conv = zext i16 %a to i32
%shr11 = lshr i16 %a, 8
%and3 = shl nuw nsw i32 %conv, 8
%conv5 = zext i16 %shr11 to i32
%or = or i32 %conv5, %and3
%conv7 = trunc i32 %or to i16
ret i16 %conv7
}
It appears the code in InstCombineAndOrXor that is trying to match a bswap
misses this case due to the zexts.
The matching code currently looks like this:
----------
// (A | B) | C and A | (B | C) -> bswap if possible.
bool OrOfOrs = match(Op0, m_Or(m_Value(), m_Value())) ||
match(Op1, m_Or(m_Value(), m_Value()));
// (A >> B) | (C << D) and (A << B) | (B >> C) -> bswap if possible.
bool OrOfShifts = match(Op0, m_LogicalShift(m_Value(), m_Value())) &&
match(Op1, m_LogicalShift(m_Value(), m_Value()));
// (A & B) | (C & D) -> bswap if possible.
bool OrOfAnds = match(Op0, m_And(m_Value(), m_Value())) &&
match(Op1, m_And(m_Value(), m_Value()));
if (OrOfOrs || OrOfShifts || OrOfAnds)
if (Instruction *BSwap = MatchBSwapOrBitReverse(I))
return BSwap;
----------
My naive guess would be to update the patterns to account for extends and then
add support for handling such extends in MatchBSwapOrBitReverse.</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>