[llvm-bugs] [Bug 37581] New: convert set-clear bit using select to bit math

[via llvm-bugs]

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

            Bug ID: 37581
           Summary: convert set-clear bit using select to bit math
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvm-bugs at lists.llvm.org

Filing this based on code in https://reviews.llvm.org/D47323 (although the
patch itself has nothing to do with this problem).

We have bit magic source like this in the LLVM optimizer:

unsigned setAllowReassoc(unsigned Flags, bool B) {
  return (Flags & ~8) | B * 8;
}

That shouldn't be necessary. This code is functionally equivalent and
(probably?) easier to understand:

unsigned setAllowReassocIf(unsigned Flags, bool B) {
  return B ? Flags | 8 : Flags & ~8;
}

The resulting x86 asm is quite different though:

$ clang++ bitmagic.c -O2 -S -o - 
        andl    $-9, %edi
        leal    (%rdi,%rsi,8), %eax
        retq

vs.     
        movl    %edi, %eax
        orl     $8, %eax
        andl    $-9, %edi
        testl   %esi, %esi
        cmovnel %eax, %edi
        movl    %edi, %eax
        retq

----------------------------------------------------------------------------

We should decide on the canonical IR:

  %and = and i32 %Flags, -9
  %conv = zext i1 %B to i32
  %mul = shl nuw nsw i32 %conv, 3
  %r = or i32 %mul, %and
=>
  %or = or i32 %Flags, 8
  %and2 = and i32 %Flags, -9
  %r = select i1 %B, i32 %or, i32 %and2


If we choose the select form (since it has less instructions), then this is a
codegen bug first. If we choose the bit-ops, then this is probably just an
instcombine bug (but we need to test codegen on other targets to make sure that
asm is better on non-x86 too).

This bug is present in clang 6.0, so it's not a result of:
https://reviews.llvm.org/D46086

That patch demonstrates possible trade-offs in our IR decision: bitops may seem
like the right choice, but they can make other analysis more difficult.

-- 
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/20180524/7b2da068/attachment.html>