Summary:
When promoting fp-to-uint16 to fp-to-sint32, the result is actually zero
extended. For example, given double 65534.0, without legalization:
fp-to-uint16: 65534.0 -> 0xfffe
With the legalization:
fp-to-sint32: 65534.0 -> 0x0000fffe
Without this patch, legalization wrongly emits a signed extend assertion,
which is consumed by later icmp instruction, and cause miscompile.
Note that the floating point value must be in [0, 65535), otherwise the
behavior is undefined.
This patch reverts r279223 behavior and adds more tests and
documentations.
In PR29041's context, James Molloy mentioned that:
We don't need to mask because conversion from float->uint8_t is
undefined if the integer part of the float value is not representable in
uint8_t. Therefore we can assume this doesn't happen!
which is totally true and good, because fptoui is documented clearly to
have undefined behavior when overflow/underflow happens. We should take
the advantage of this behavior so that we can save unnecessary mask
instructions.
Reviewers: jmolloy, nadav, echristo, kbarton
Subscribers: mehdi_amini, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28284
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291015
91177308-0d34-0410-b5e6-
96231b3b80d8
// Assert that the converted value fits in the original type. If it doesn't
// (eg: because the value being converted is too big), then the result of the
// original operation was undefined anyway, so the assert is still correct.
- return DAG.getNode(NewOpc == ISD::FP_TO_UINT ?
+ //
+ // NOTE: fp-to-uint to fp-to-sint promotion guarantees zero extend. For example:
+ // before legalization: fp-to-uint16, 65534. -> 0xfffe
+ // after legalization: fp-to-sint32, 65534. -> 0x0000fffe
+ return DAG.getNode(N->getOpcode() == ISD::FP_TO_UINT ?
ISD::AssertZext : ISD::AssertSext, dl, NVT, Res,
DAG.getValueType(N->getValueType(0).getScalarType()));
}
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64"
+; If the float value is negative or too large, the result is undefined anyway;
+; otherwise, fcvtzs must returns a value in [0, 256), which guarantees zext.
+
; CHECK-LABEL: float_char_int_func:
; CHECK: fcvtzs [[A:w[0-9]+]], s0
-; CHECK-NEXT: and w0, [[A]], #0xff
; CHECK-NEXT: ret
define i32 @float_char_int_func(float %infloatVal) {
entry:
--- /dev/null
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -O0 < %s | FileCheck %s
+target triple = "powerpc64le--linux-gnu"
+
+define i1 @Test(double %a) {
+; CHECK-LABEL: Test:
+; CHECK: # BB#0: # %entry
+; CHECK-NEXT: xscvdpsxws 1, 1
+; CHECK-NEXT: mfvsrwz 3, 1
+; CHECK-NEXT: xori 3, 3, 65534
+; CHECK-NEXT: cntlzw 3, 3
+; CHECK-NEXT: srwi 3, 3, 5
+; CHECK-NEXT: # implicit-def: %X4
+; CHECK-NEXT: mr 4, 3
+; CHECK-NEXT: mr 3, 4
+; CHECK-NEXT: blr
+entry:
+ %conv = fptoui double %a to i16
+ %cmp = icmp eq i16 %conv, -2
+ ret i1 %cmp
+}