[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