LLVM 14 Regression: Bad fptoui result when targeting x86_64-windows-gnu

[topolarity]

Bad float to int conversion when targeting x86_64-windows-gnu:

; ModuleID = 'test'
source_filename = "test"
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-windows-gnu"

; Function Attrs: nobuiltin nounwind uwtable
define external fastcc i16 @"wWinMainCRTStartup"() unnamed_addr #1 {
Entry:
  %x = alloca double, align 8
  store double 152314000000000000407048814592.0, double* %x, align 8
  %0 = load double, double* %x, align 8
  %1 = fptoui double %0 to i128
  %2 = icmp ne i128 %1, 152314000000000000407048814592
  %3 = zext i1 %2 to i32
  call void @ExitProcess(i32 %3)
  unreachable
}

; Function Attrs: nobuiltin noreturn nounwind uwtable
declare void @ExitProcess(i32 %0) #2

This exits with 0 in LLVM 13.0.1, but returns 1 with LLVM 14.0.5 and trunk.

(Note that 152314000000000000407048814592 is exactly representable in both f64 and u128)

[topperc]

This seems to produce the same assembly with llc on trunk and llvm 13. https://godbolt.org/z/qY1je758n are you seeing something different?

[topperc]

It does produce different assembly with -O0. Is that what I'm meant to use?

[topperc]

The issue I'm seeing on -O0 is with the calling convention for the __fixunsdfti libcall which was changed by this patch https://reviews.llvm.org/D110413

[topolarity]

It does produce different assembly with -O0. Is that what I'm meant to use?

Oh yes. Sorry for forgetting to add that detail - This is at -O0

[topolarity]

I was unaware of the calling convention change - Thanks for the information.

It's possible this is just an ABI mismatch with the __fixunsdtfi implementation we're providing downstream. I'll investigate more soon

[topolarity]

It looks like this is indeed just an ABI mismatch - I've confirmed using compiler-rt compiled using clang on Windows fixes the problem.

Apologies for the noise, and thank you for your help.