[x86] fix miscompile from wrongly identified fneg

We may need to peek through a bitcast when identifying an fneg idiom
via its pool constant, but we can't allow a different-sized constant
in that match.

This is noted in issue #55758 with an example that needs fast-math,
but as the test here shows, this has potential to miscompile more
generally (no fast-math required).

Differential Revision: https://reviews.llvm.org/D126775
This commit is contained in:
Sanjay Patel 2022-06-01 09:46:29 -04:00
parent ffa479a452
commit 3a503a4a9c
2 changed files with 10 additions and 4 deletions

View File

@ -50129,10 +50129,14 @@ static SDValue isFNEG(SelectionDAG &DAG, SDNode *N, unsigned Depth = 0) {
if (!UndefElts[I] && !EltBits[I].isSignMask())
return SDValue();
return peekThroughBitcasts(Op0);
// Only allow bitcast from correctly-sized constant.
Op0 = peekThroughBitcasts(Op0);
if (Op0.getScalarValueSizeInBits() == ScalarSize)
return Op0;
}
}
}
break;
} // case
} // switch
return SDValue();
}

View File

@ -82,11 +82,13 @@ define float @fdiv_extra_use_changes_cost(float %a0, float %a1, float %a2) nounw
ret float %div5
}
; FIXME: PR55758 - this is not -(-X)
; PR55758 - this is not -(-X)
define <2 x i64> @fneg_mismatched_sizes(<4 x float> %x) {
; CHECK-LABEL: fneg_mismatched_sizes:
; CHECK: # %bb.0:
; CHECK-NEXT: xorps {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
; CHECK-NEXT: xorps {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
; CHECK-NEXT: retl
%n = fneg <4 x float> %x
%b = bitcast <4 x float> %n to <2 x i64>