Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"optimized" range comparison not simplified #1625

Closed
llvmbot opened this issue Mar 12, 2007 · 4 comments
Closed

"optimized" range comparison not simplified #1625

llvmbot opened this issue Mar 12, 2007 · 4 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla code-quality

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 12, 2007

Bugzilla Link 1253
Resolution FIXED
Resolved on Feb 22, 2010 12:48
Version 1.0
OS Linux
Reporter LLVM Bugzilla Contributor

Extended Description

The condition a<=x<=b can be transformed into (unsigned)n-a<=b-a.
However if a=INT_MIN then this "optimization" leads to suboptimal
code:

#include <limits.h>
int bad (int n) {
return ((unsigned)n-INT_MIN<=-1-INT_MIN);
}

->

define i32 @​bad(i32 %n) {
entry:
%tmp2 = xor i32 %n, -2147483648 ; [#uses=1]
icmp sgt i32 %tmp2, -1 ; :0 [#uses=1]
zext i1 %0 to i32 ; :0 [#uses=1]
ret i32 %0
}

This would be better as: "return n<0;"

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 12, 2007

assigned to @lattner

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 14, 2007

i.e. this example shows that replacing ult with slt (and presumably
vice-versa) can be advantageous, but this is not exploited.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 27, 2007

I forgot to mention where this comes from: the gcc -> llvm switch
conversion code lowers wide case ranges to explicit conditional
branches. The test that x is in the range lo .. hi is emitted as
"x-lo ule hi-lo". If lo is INT_MIN then this results in suboptimal
code, as explained in this PR. I could have checked for this case
explicitly in the switch conversion code, but I didn't want to do so
because it is really a job for the optimizers: they should be able to
handle this case. Oddly enough, if you emit the test as "(x>=lo)&&(x<=hi)"
then it gets simplified optimally.

@lattner
Copy link
Collaborator

lattner commented Apr 3, 2007

Fixed, testcase here: Transforms/InstCombine/xor2.ll:test[01]
Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070402/046701.html

This handles the general case of a xor constant, not just this specific one.

-Chris

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla code-quality
Projects
None yet
Development

No branches or pull requests

2 participants