[PATCH] D141074: [X86] Avoid converting 64-bit integers to floating point using x87 on Windows

[icedrocket via Phabricator via llvm-commits]

icedrocket updated this revision to Diff 489489.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141074/new/

https://reviews.llvm.org/D141074

Files:
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/uint64-to-float.ll


Index: llvm/test/CodeGen/X86/uint64-to-float.ll
===================================================================
--- llvm/test/CodeGen/X86/uint64-to-float.ll
+++ llvm/test/CodeGen/X86/uint64-to-float.ll
@@ -1,6 +1,8 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc < %s -mtriple=i686-apple-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
-; RUN: llc < %s -mtriple=x86_64-apple-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
+; RUN: llc < %s -mtriple=i686-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
+; RUN: llc < %s -mtriple=i686-windows -mattr=+sse2 | FileCheck %s --check-prefix=X86_WIN
+; RUN: llc < %s -mtriple=x86_64-windows -mattr=+sse2 | FileCheck %s --check-prefix=X64_WIN
 
 ; Verify that we are using the efficient uitofp --> sitofp lowering illustrated
 ; by the compiler_rt implementation of __floatundisf.
@@ -42,6 +44,36 @@
 ; X64-NEXT:    cvtsi2ss %rdi, %xmm0
 ; X64-NEXT:    addss %xmm0, %xmm0
 ; X64-NEXT:    retq
+;
+; X86_WIN-LABEL: test:
+; X86_WIN:       # %bb.0: # %entry
+; X86_WIN-NEXT:    pushl %ebp
+; X86_WIN-NEXT:    movl %esp, %ebp
+; X86_WIN-NEXT:    andl $-8, %esp
+; X86_WIN-NEXT:    subl $8, %esp
+; X86_WIN-NEXT:    pushl 12(%ebp)
+; X86_WIN-NEXT:    pushl 8(%ebp)
+; X86_WIN-NEXT:    calll ___floatundisf
+; X86_WIN-NEXT:    addl $8, %esp
+; X86_WIN-NEXT:    movl %ebp, %esp
+; X86_WIN-NEXT:    popl %ebp
+; X86_WIN-NEXT:    retl
+;
+; X64_WIN-LABEL: test:
+; X64_WIN:       # %bb.0: # %entry
+; X64_WIN-NEXT:    testq %rcx, %rcx
+; X64_WIN-NEXT:    js .LBB0_1
+; X64_WIN-NEXT:  # %bb.2: # %entry
+; X64_WIN-NEXT:    cvtsi2ss %rcx, %xmm0
+; X64_WIN-NEXT:    retq
+; X64_WIN-NEXT:  .LBB0_1:
+; X64_WIN-NEXT:    movq %rcx, %rax
+; X64_WIN-NEXT:    shrq %rax
+; X64_WIN-NEXT:    andl $1, %ecx
+; X64_WIN-NEXT:    orq %rax, %rcx
+; X64_WIN-NEXT:    cvtsi2ss %rcx, %xmm0
+; X64_WIN-NEXT:    addss %xmm0, %xmm0
+; X64_WIN-NEXT:    retq
 entry:
   %b = uitofp i64 %a to float
   ret float %b
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===================================================================
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -21882,6 +21882,13 @@
   }
 
   assert(SrcVT == MVT::i64 && "Unexpected type in UINT_TO_FP");
+
+  // On Windows, the default precision control on x87 is only 53-bit, and FADD
+  // triggers rounding with that precision, so the final result may be less
+  // accurate. 18014397972611071 is one such case.
+  if (Subtarget.isOSWindows())
+    return SDValue();
+
   SDValue ValueToStore = Src;
   if (isScalarFPTypeInSSEReg(Op.getValueType()) && !Subtarget.is64Bit()) {
     // Bitcasting to f64 here allows us to do a single 64-bit store from


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D141074.489489.patch
Type: text/x-patch
Size: 2831 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230116/77b4c3b2/attachment.bin>