64-bit long double for x86-64?

[Andarwinux]

It seems that llvm-mingw used to define the x86-64 long double as 80-bit for gcc compatibility, which made many UCRT math functions unusable.
But nowadays llvm-mingw is not gcc-compatible anyway, so would it be possible to add a 64-bit variant of long double for x86-64 to improve performance and MSVC compatibility?
This seems to require a modification on the MinGW CRT side, and -mlong-double-64 won't work.

[mstorsjo]

But nowadays llvm-mingw is not gcc-compatible anyway

Can you quantify what you refer to here? llvm-mingw is generally ABI compatible with GCC. C++ code that refers to the standard C++ library isn't compatible across C++ libraries of course though. And object files/static libraries built for UCRT isn't generally safe to mix with similar ones built for msvcrt.dll - but that's not an issue specific to llvm-mingw or Clang vs GCC.

so would it be possible to add a 64-bit variant of long double for x86-64 to improve performance and MSVC compatibility?
This seems to require a modification on the MinGW CRT side

Yes, this would require quite large modifications there.

If you want the performance of 64 bit doubles, use double, not long double.

[mstorsjo]

If you want the performance of 64 bit doubles, use double, not long double.

To provide more context on this; e.g. on aarch64 linux, long double is actually 128 bit softfloats. (For aarch64 mingw, we did match MSVC and just went with plain 64 bit doubles - matching what MSVC does, does have its advantages of course. But at this point, changing it for x86 would be a large amount of work and lots of conditionals in mingw-w64, especially when the x87 long doubles have to be kept for GCC.)

[Andarwinux]

Can you quantify what you refer to here? llvm-mingw is generally ABI compatible with GCC. C++ code that refers to the standard C++ library isn't compatible across C++ libraries of course though. And object files/static libraries built for UCRT isn't generally safe to mix with similar ones built for msvcrt.dll - but that's not an issue specific to llvm-mingw or Clang vs GCC.

The main incompatibilities are toolchain runtime: compiler-rt, libc++, libunwind, but there are still some incompatibilities besides that which are not related to runtime: CFGuard, AVX512, TLS, LTO. Anyway, apart from msys2 mingw64/ucrt64 env, there is no other llvm-mingw distribution specifically configured to be compatible with GCC.

If you want the performance of 64 bit doubles, use double, not long double.

I'm sorry, but I'm only using llvm-mingw to build software, so it's not something I can decide.
For some software, VTune says a lot of CPU time is wasted on MinGW's slow math functions, and since its implementation is inline x87, even -O3 -march=native doesn't help, which creates an unbridgeable performance gap compared to MSVC/Clang-CL builds. After some searching, I found that the 80-bit long double was the cause of the inability to use the UCRT implementation. I'm just hoping to get rid of the 80-bit long double to solve this problem, just like aarch64.

[mstorsjo]

Can you quantify what you refer to here? llvm-mingw is generally ABI compatible with GCC. C++ code that refers to the standard C++ library isn't compatible across C++ libraries of course though. And object files/static libraries built for UCRT isn't generally safe to mix with similar ones built for msvcrt.dll - but that's not an issue specific to llvm-mingw or Clang vs GCC.

The main incompatibilities are toolchain runtime: compiler-rt, libc++, libunwind

Compiler-rt and libunwind are only implementation differences, and they are ABI compatible with libgcc.

but there are still some incompatibilities besides that which are not related to runtime: CFGuard, AVX512, TLS, LTO.

TLS is indeed a bit of an issue, but there are actually things happening in GCC to move towards native TLS here.

The rest also isn't about ABI differences, but just differing sets of features or how to invoke them - not ABI level incompatibilities.

In any case - your wish is noted.

[carlkl]

@Andarwinux: Currently I'm working on this: creating patches for mingw-w64 to be compatible with -mlong-double-64. However, I only have a low rate of progress at the time.
The disadvantge of this approach is: such patches will most likely never be accepted upstream and to keep patches like this healthy in the long term is quite a bit of effort.

[Andarwinux]

@Andarwinux: Currently I'm working on this: creating patches for mingw-w64 to be compatible with -mlong-double-64. However, I only have a low rate of progress at the time. The disadvantge of this approach is: such patches will most likely never be accepted upstream and to keep patches like this healthy in the long term is quite a bit of effort.

Good to know! It would be nice to have it as an experimental option disabled by default. I think @cjacek might be interested in your work, which might also help with arm64ec.

[cjacek]

Yes, I hope we can have support for that upstream.