mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 12:12:47 +01:00
2485ce4de5
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 llvm-svn: 291015
18 lines
530 B
LLVM
18 lines
530 B
LLVM
; RUN: llc < %s | FileCheck %s
|
|
|
|
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: ret
|
|
define i32 @float_char_int_func(float %infloatVal) {
|
|
entry:
|
|
%conv = fptoui float %infloatVal to i8
|
|
%conv1 = zext i8 %conv to i32
|
|
ret i32 %conv1
|
|
}
|