[llvm-bugs] [Bug 27824] New: [InstCombine][AArch64] Missed bswap opportunities for i16

[via llvm-bugs]

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

            Bug ID: 27824
           Summary: [InstCombine][AArch64] Missed bswap opportunities for
                    i16
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: mcrosier at codeaurora.org
                CC: david.majnemer at gmail.com, llvm-bugs at lists.llvm.org,
                    t.p.northover at gmail.com
    Classification: Unclassified

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.

-- 
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/20160520/42ad361b/attachment.html>