-
Notifications
You must be signed in to change notification settings - Fork 14.4k
release/20.x: [ValueTracking] Bail out on x86_fp80 when computing fpclass with knownbits (#130477) #130489
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
Conversation
@arsenm What do you think about merging this PR to the release branch? |
@llvm/pr-subscribers-llvm-analysis @llvm/pr-subscribers-llvm-transforms Author: None (llvmbot) ChangesBackport 029e102 Requested by: @dtcxzyw Full diff: https://github.com/llvm/llvm-project/pull/130489.diff 2 Files Affected:
diff --git a/llvm/lib/Analysis/ValueTracking.cpp b/llvm/lib/Analysis/ValueTracking.cpp
index 8a674914641a8..4e79f41df2eb9 100644
--- a/llvm/lib/Analysis/ValueTracking.cpp
+++ b/llvm/lib/Analysis/ValueTracking.cpp
@@ -6135,13 +6135,14 @@ void computeKnownFPClass(const Value *V, const APInt &DemandedElts,
else if (Bits.isNegative())
Known.signBitMustBeOne();
- if (Ty->isIEEE()) {
+ if (Ty->isIEEELikeFPTy()) {
// IEEE floats are NaN when all bits of the exponent plus at least one of
// the fraction bits are 1. This means:
// - If we assume unknown bits are 0 and the value is NaN, it will
// always be NaN
// - If we assume unknown bits are 1 and the value is not NaN, it can
// never be NaN
+ // Note: They do not hold for x86_fp80 format.
if (APFloat(Ty->getFltSemantics(), Bits.One).isNaN())
Known.KnownFPClasses = fcNan;
else if (!APFloat(Ty->getFltSemantics(), ~Bits.Zero).isNaN())
diff --git a/llvm/test/Transforms/InstSimplify/fcmp.ll b/llvm/test/Transforms/InstSimplify/fcmp.ll
index 64132f5fb7db7..0c2be5210a741 100644
--- a/llvm/test/Transforms/InstSimplify/fcmp.ll
+++ b/llvm/test/Transforms/InstSimplify/fcmp.ll
@@ -16,3 +16,20 @@ define i1 @poison2(float %x) {
%v = fcmp ueq float %x, poison
ret i1 %v
}
+
+define i1 @pr130408(x86_fp80 %x) {
+; CHECK-LABEL: @pr130408(
+; CHECK-NEXT: [[BITS:%.*]] = bitcast x86_fp80 [[X:%.*]] to i80
+; CHECK-NEXT: [[MASKED:%.*]] = and i80 [[BITS]], -604444463063240877801473
+; CHECK-NEXT: [[OR:%.*]] = or i80 [[MASKED]], 302194561415509874573312
+; CHECK-NEXT: [[FP:%.*]] = bitcast i80 [[OR]] to x86_fp80
+; CHECK-NEXT: [[RES:%.*]] = fcmp uno x86_fp80 [[FP]], 0xK00000000000000000000
+; CHECK-NEXT: ret i1 [[RES]]
+;
+ %bits = bitcast x86_fp80 %x to i80
+ %masked = and i80 %bits, -604444463063240877801473
+ %or = or i80 %masked, 302194561415509874573312
+ %fp = bitcast i80 %or to x86_fp80
+ %res = fcmp uno x86_fp80 %fp, 0xK00000000000000000000
+ ret i1 %res
+}
|
…nbits (llvm#130477) In llvm#97762, we assume the minimum possible value of X is NaN implies X is NaN. But it doesn't hold for x86_fp80 format. If the knownbits of X are `?'011111111111110'????????????????????????????????????????????????????????????????`, the minimum possible value of X is NaN/unnormal. However, it can be a normal value. Closes llvm#130408. (cherry picked from commit 029e102)
@dtcxzyw (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR. |
Backport 029e102
Requested by: @dtcxzyw