[llvm-bugs] [Bug 27105] New: [InstCombine] missing canonicalization for binop + compare against constant

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Mar 28 17:39:01 PDT 2016


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

            Bug ID: 27105
           Summary: [InstCombine] missing canonicalization for binop +
                    compare against constant
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

This is based on a long trail off of:
http://reviews.llvm.org/D18513

int foo(int i) {
  // 0x71 could be any constant
  // -1 could be any constant?
  // Bitwise OR could be any bitwise binop?
  return (i | 0x71) == -1; 
}

We can negate both sides of the equation to transform that comparison to:

int foo(int i) {
  return (~i & ~0x71) == 0;
}

Now this is actually the form that we want for an x86 machine with BMI: that's
a NAND + comparison against zero - it's one instruction! It might even be worth
it for any x86 machine if a 'not' is better than an explicit compare inst.

(We still have to get the zero flag (ZF) bit into an integer register, but I
don't think there's any way to avoid that.)

But InstCombine wants to reduce the IR, so it becomes:

int foo(int i) {
  return (i & ~0x71) == ~0x71;
}

So at the least, the backend has to recognize that pattern. But I think
InstCombine should be taking the original code and producing that as the
canonical form because we now have one constant instead of two.

-- 
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/20160329/420b1fd2/attachment.html>


More information about the llvm-bugs mailing list