ppc64(le): Add an option to use IEEE long double ABI on Linux #4833

liushuyu · 2025-02-01T23:48:29Z

This pull request adds an option to use IEEE long double ABI on Linux (if the host environment supports it).

Some adjustments are made to accommodate the new ABI (glibc uses dual-ABI in this case, where new IEEE long double-capable functions are suffixed with __ieee128; older functions using IBM long double are also kept for compatibility reasons).

liushuyu · 2025-02-01T23:49:17Z

During the porting process, I discovered what seems to be an LLVM bug when targeting ppc64 using the IEEE long double ABI. Consider the following D code:

extern (C++) real test1(real arg0)
{
  if (!(arg0 == 0.0))
  {
    return 0.0;
  }
  else
  {
    return 0.0;
  }
}

LDC will generate the following LLVM IR (reduced, no optimization):

  target datalayout = "e-m:e-Fn32-i64:64-i128:128-n32:64-S128-v256:256:256-v512:512:512"
  target triple = "powerpc64le-unknown-linux-gnu"

  define fp128 @_Z5test1u9__ieee128(fp128 %0) {
    %2 = fcmp ogt fp128 %0, 0xL00000000000000000000000000000000
    %3 = icmp i1 %2, false
    br i1 %3, label %5, label %4

  4:                                                ; preds = %1
    ret fp128 0xL00000000000000000000000000000000

  5:                                                ; preds = %1
    ret fp128 0xL00000000000000000000000000000000
  }

... which will lead to what seems to be an infinite ppc-isel expansion loop inside LLVM.

I have added a workaround solution in this pull request to replace icmp .., false with xor .., true when lowering a "not" operator.

JohanEngelen · 2025-02-02T18:02:15Z

During the porting process, I discovered what seems to be an LLVM bug when targeting ppc64 using the IEEE long double ABI.

Please also report the bug in LLVM's bug tracker.

Nice that you are working on this btw !

driver/targetmachine.cpp

driver/main.cpp

JohanEngelen · 2025-02-02T18:11:02Z

runtime/druntime/src/core/thread/fiber.d

@@ -570,6 +570,8 @@ version (LDC)

    version (AArch64) version = CheckFiberMigration;

+    version (PPC64)   version = CheckFiberMigration;


intended change?

Yes, this is intended change. I fixed this after running the basic unit tests

To add to my last comment, that issue was not discovered because the D Phobos library needs IEEE 128-bit arithmetic to work, which was not implemented before this pull request.

JohanEngelen · 2025-02-02T18:11:28Z

would be good to add a lit testcase for setting this abi param

liushuyu · 2025-02-02T20:02:23Z

would be good to add a lit testcase for setting this abi param

Will do

liushuyu · 2025-02-04T23:45:15Z

During the porting process, I discovered what seems to be an LLVM bug when targeting ppc64 using the IEEE long double ABI.

Please also report the bug in LLVM's bug tracker.

Nice that you are working on this btw !

Thanks! I have proposed a fix to the LLVM upstream regarding this issue: llvm/llvm-project#125776

liushuyu · 2025-02-06T01:15:47Z

Corresponding DMD pull request: dlang/dmd#20826

liushuyu · 2025-02-15T21:09:15Z

I think this is ready for review. I found some additional issues with druntime and phobos during testing, but the compiler works very well.

kinke · 2025-02-15T21:14:02Z

gen/abi/ppc64le.cpp

 #include "gen/irstate.h"
 #include "gen/llvmhelpers.h"
 #include "gen/tollvm.h"

 using namespace dmd;

+struct LongDoubleRewrite : ABIRewrite {


I don't think we need this rewrite. The D real values (Tfloat80 etc.) are already IR-emitted as doubledouble or IEEE quad by the changes in target.cpp. The compiler represents all compile-time floating-point values via real_t, which is the D host compiler's real on non-x86. Compile-time real_t and the target real diverging can easily happen during cross-compilation (e.g., x87 real_t for x86 compilers cross-compiling to quad real for Linux AArch64). There's according APFloat conversion happening for IR emission already. The resulting limitations, incl. dangers of compile-time over/underflows when cross-compiling to a target with greater real precision, are mentioned in https://wiki.dlang.org/Cross-compiling_with_LDC#Limitations.

kinke · 2025-02-15T21:28:22Z

runtime/druntime/src/core/stdc/math.d

@@ -4284,404 +4284,651 @@ else
    double  acos(double x);
    ///
    float   acosf(float x);
-    ///
-    real    acosl(real x);


I doubt this will be accepted upstream, this break-up of the default block, and so think it'd be better to add a new top-level block here at line 4281 with static if (PPCUseIEEE128). All the BSDs, MSVC, Bionic, uclibc etc. have their special-cases kept away in their separate blocks - more duplication, but less cluttering with special cases all over the place.

I doubt this will be accepted upstream, this break-up of the default block, and so think it'd be better to add a new top-level block here at line 4281 with static if (PPCUseIEEE128). All the BSDs, MSVC, Bionic, uclibc etc. have their special-cases kept away in their separate blocks - more duplication, but less cluttering with special cases all over the place.

This is actually the version accepted upstream, you can see it here: dlang/dmd@9ae8b3e

kinke · 2025-02-15T21:35:57Z

runtime/druntime/src/core/atomic.d

+            version (D_PPCUseIEEE128) 
+                enum has128BitCAS = true;
+            else
+                enum has128BitCAS = false;


enum has128BitCAS = real.mant_dig == 113, then we don't need the extra predefined version anymore.

Please note that there's one catch with static if vs. a version(…) - the former is semantically analyzed later, versions are resolved really early. If unlucky, forward referencing errors can occur. But if druntime and the test runners can still be built successfully, we might get away without extra predefined version.

kinke · 2025-02-15T21:38:31Z

gen/target.cpp

@@ -240,6 +264,19 @@ const char *TargetCPP::typeMangle(Type *t) {
    // `long double` on Android/x64 is __float128 and mangled as `g`
    bool isAndroidX64 = triple.getEnvironment() == llvm::Triple::Android &&
                        triple.getArch() == llvm::Triple::x86_64;
+    if (triple.getArch() == llvm::Triple::ppc64 ||
+        triple.getArch() == llvm::Triple::ppc64le) {
+      if (global.params.ppcUseIEEE128 &&


target.RealProperties.mant_dig == 113 should work as well

kinke · 2025-02-15T21:39:27Z

gen/target.cpp

+          triple.getEnvironment() == llvm::Triple::GNU) {
+        return "u9__ieee128";
+      }
+      if (size(t) == 16) {


target.realsize, or another property

kinke · 2025-02-15T21:53:27Z

driver/cl_options.cpp

+           // special handling for ieeelongdouble options
+           // note that, it is expected if we did not see any previous mabi
+           // options, we reset mABI variable to empty
+           if (Arg == "ieeelongdouble") {


I understand this would be clang-compatible, but still, we don't have long double in D, that's real.

I guess another option could be something like -real-precision=<double|quad>, for all targets, a cmdline option that we could embed in gen/target.cpp, as we only need it to choose/override the target real type (and then wouldn't need a global.params.ppcUseIEEE128). Only supporting the two IEEE variants, no x87 and doubledouble exotics. -real-precision=double could e.g. also come in handy for webassembly in #4838, as a way to deal with existing real code (people unfortunately use it in D much more often than long double in C...).

I understand this would be clang-compatible, but still, we don't have long double in D, that's real.

I guess another option could be something like -real-precision=<double|quad>, for all targets, a cmdline option that we could embed in gen/target.cpp, as we only need it to choose the target real type (and then wouldn't need a global.params.ppcUseIEEE128). Only supporting the two IEEE variants, no x87 and doubledouble exotics. -real-precision=double could e.g. also come in handy for webassembly in #4838, as a way to deal with existing real code (people unfortunately use it in D much more often than long double in C...).

Then how do we express -mabi=ibmlongdouble in the case of LDC? I know the idea might be use IEEE quad as much as possible, but I think at least in the case of POWER platforms, a compatibility escape hatch is still needed (a lot of Linux distros still default to IBM double double for their system C libraries).

IIUC, doubledouble is currently the default setting when targeting glibc, so one wouldn't have to override the default with -real-precision. But yeah, I guess it would make sense to default to IEEE quad when adding support for it now in 2025, or at least have the option to default to it at one point in the future. So yeah, -real-precision might have to include x87 and doubledouble too.

IIUC, doubledouble is currently the default setting when targeting glibc, so one wouldn't have to override the default with -real-precision. But yeah, I guess it would make sense to default to IEEE quad when adding support for it now in 2025, or at least have the option to default to it at one point in the future. So yeah, -real-precision might have to include x87 and doubledouble too.

I have added a new option -real-precision=<double|quad|platform> for this (platform = platform-specific encoding, on x86 this would be x87 and on ppc64le this would be IBM double-double)

kinke · 2025-02-15T22:03:19Z

CMakeLists.txt

+    elseif ( NOT HAS_IBM_LONG_DOUBLE )
+        # usually the case for musl/uclibc
+        append("-mlong-double-64" LDC_CXXFLAGS)
+    endif()


Wait, you check the default behavior of the C++ compiler, so we shouldn't need any explicit C++ flags. [Unless you wanna override the LLVM flags.] The D host compiler might need a flag though, to make sure it's real matches the C++ long double, at least for the IEEE-quad case, which needs explicit opting it in with (new) LDC compilers.

Hmm, I admit that might be a mistake. I will fix this.

Actually it's a bit more complicated than that - host druntime and Phobos need to be (pre)compiled with the same ABI setting, matching the C++/LLVM one.

Actually it's a bit more complicated than that - host druntime and Phobos need to be (pre)compiled with the same ABI setting, matching the C++/LLVM one.

This one might need to be documented. According to my testing, changing the host druntime files in include directory is enough to get new LDC bootstrapped (using GDC/GDMD).

Yeah. But as adding some D flag wouldn't be sufficient then anyway, we probably don't need to try to add some here in CMake anymore. Host C++ and D compilers need to target the same ABI when building LDC; if the D one needs tweaking via extra flag, host druntime and Phobos need to be built accordingly and selected too, as in a cross-compile scenario.

[You were probably lucky that a few binding adaptations in the source files were enough to fix up host druntime, without having to rebuild the library.]

Done. CMake files fixed

You now affect the new druntime and Phobos builds for the just-built LDC, compiling them with the same ABI setting as the compiler itself. It doesn't affect (and cannot) host druntime and Phobos (from GDC in your case), which need to be precompiled with the same ABI setting (as they are linked into the LDC executable).

Now suppose LDC was built on a PPC system with (default) IEEE quad ABI. New druntime and Phobos would be compiled with -real-precision=quad. But when the user runs it with ldc2 hello.d, he'd get a hello object file compiled with default doubledouble ABI, linked with druntime and Phobos using the IEEE ABI. As the D real mangling isn't affected by its precision, the user wouldn't get undefined symbols, but most likely just corrupt floating-point values at runtime.

So a distro package maintainer would in that case need to make sure the compiler defaults to the same ABI as the bundled precompiled druntime and Phobos. E.g., by adding a PPC section in ldc2.conf, adding -real-precision=quad as default switch.

So as said, I think it'd be best to just remove all of this CMake flag fiddling for PPC - it's not enough, the user/package maintainer has to get involved and provide explicit flags in case the default host compiler ABIs diverge, and/or a non-default ABI is desired. As long as using GDC as host compiler, the compilers most likely default to the same ABI. [And there's probably a long way to go until LDC can build itself on such platforms, that requires full C ABI compatibility (ABI rewrites to help LLVM do the right thing) and full C-style variadic arguments support.]

What we could also do: for a native ppc compiler build, default to the real precision of the host. So a native IEEE-quad build would default to -real-precision=quad (incl. druntime and Phobos automatically precompiled with that ABI setting).

Okay, I have now put these inside ldc2*.conf files.

... and then add a long double rewrite to convert it to ppc_f128 when lowering

... if -mabi=ieeelongdouble is specified on ppc64

... if IEEE long double ABI is selected

... to avoid a LLVM bug on multiple platforms

This will allow the user to specify -real-precision=quad + -mabi=elfv1 together without changing how LDC parses mabi options

liushuyu · 2025-02-16T02:32:37Z

FreeBSD CI is broken because Google Cloud no longer has the 13.3 image (the oldest supported image is FreeBSD 13.4).

... the system is using the new ABI that supports IEEE 754R long double instead of the legacy IBM double double format

ABI switching

liushuyu · 2025-02-16T21:14:13Z

Also GitHub says: actions/runner-images#11101

the-horo · 2025-02-16T21:36:30Z

ldc2.conf.in

+{
+    // default to IEEE quad precision
+    // if your platform does not support this, feel free to remove it.
+    switches = ["--real-precision=quad"]


Arrays are not cumulative in ldc2.conf so what you did removed -defaultlib=druntime-ldc from the default switches for ppc64le

kinke · 2025-02-18T21:21:26Z

This is how I imagine it, without being able to test anything: #4840

JohanEngelen reviewed Feb 2, 2025

View reviewed changes

driver/targetmachine.cpp Outdated Show resolved Hide resolved

JohanEngelen reviewed Feb 2, 2025

View reviewed changes

driver/main.cpp Outdated Show resolved Hide resolved

JohanEngelen reviewed Feb 2, 2025

View reviewed changes

liushuyu force-pushed the ppc64-d-ieee754-fix-new branch from 9b8fd56 to 2361ed6 Compare February 5, 2025 21:55

liushuyu mentioned this pull request Feb 6, 2025

druntime: redirect dual-ABI functions on glibc to IEEE128 version dlang/dmd#20826

Merged

liushuyu force-pushed the ppc64-d-ieee754-fix-new branch from 2361ed6 to a644c57 Compare February 14, 2025 22:35

liushuyu marked this pull request as ready for review February 15, 2025 21:08

kinke reviewed Feb 15, 2025

View reviewed changes

liushuyu added 9 commits February 15, 2025 19:15

gen: use IEEE128 on ppc64le internally ...

05ccbb7

... and then add a long double rewrite to convert it to ppc_f128 when lowering

gen: use ppc_f128 or fp128 on ppc64le depending on the ABI switch

7802f8d

driver: add D_PPCUseIEEE128 pre-defined version ...

d892d68

... if -mabi=ieeelongdouble is specified on ppc64

druntime: redirect dual-ABI functions on glibc to IEEE128 version ...

84c6a2b

... if IEEE long double ABI is selected

gen/modules.cpp: add PowerPC float-abi metadata marking

eb7c41c

gen/toir.cpp: use xor operator to emulate unary not operation ...

b0ab201

... to avoid a LLVM bug on multiple platforms

gen/target.cpp: special C++ mangling for ppc64

a698caf

gen/abi/ppc64le.cpp: fix zext/sext for vector types

4e7800d

runtime/fiber: enable CheckFiberMigration for ppc64

26034e5

liushuyu added 4 commits February 15, 2025 19:15

runtime/atomic: enable 128BitCAS for ppc64 when using IEEE 128 ABI

f6d20f4

driver/main + gen/target: fix environment detection for ppc64 real type

5180b4d

CHANGELOG.md: document ppc64 and ppc64le IEEE 128 support changes

4151349

gen+driver: use a different approach to parse and pass IEEE 128 options

ae4c0d8

This will allow the user to specify -real-precision=quad + -mabi=elfv1 together without changing how LDC parses mabi options

liushuyu force-pushed the ppc64-d-ieee754-fix-new branch from a644c57 to 739cd9b Compare February 16, 2025 02:15

liushuyu force-pushed the ppc64-d-ieee754-fix-new branch 2 times, most recently from b485bdc to a413d1f Compare February 16, 2025 20:17

liushuyu added 2 commits February 16, 2025 13:35

cmake: do not turn off long double on ppc64 if ...

5195def

... the system is using the new ABI that supports IEEE 754R long double instead of the legacy IBM double double format

tests/driver/ppc_float_abi.d: add a test to test ppc64 real type

96c455c

ABI switching

liushuyu force-pushed the ppc64-d-ieee754-fix-new branch from a413d1f to 96c455c Compare February 16, 2025 20:36

the-horo reviewed Feb 16, 2025

View reviewed changes

kinke mentioned this pull request Feb 18, 2025

ppc64(le): Add an option to use IEEE long double ABI on Linux [2] #4840

Merged

kinke merged commit 96c455c into ldc-developers:master Feb 20, 2025
19 of 20 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ppc64(le): Add an option to use IEEE long double ABI on Linux #4833

ppc64(le): Add an option to use IEEE long double ABI on Linux #4833

liushuyu commented Feb 1, 2025

liushuyu commented Feb 1, 2025 •

edited

Loading

JohanEngelen commented Feb 2, 2025

JohanEngelen Feb 2, 2025

liushuyu Feb 2, 2025

liushuyu Feb 4, 2025

JohanEngelen commented Feb 2, 2025

liushuyu commented Feb 2, 2025

liushuyu commented Feb 4, 2025

liushuyu commented Feb 6, 2025

liushuyu commented Feb 15, 2025

kinke Feb 15, 2025

kinke Feb 15, 2025

liushuyu Feb 15, 2025

kinke Feb 15, 2025

kinke Feb 15, 2025

kinke Feb 15, 2025

kinke Feb 15, 2025 •

edited

Loading

liushuyu Feb 15, 2025

kinke Feb 15, 2025

liushuyu Feb 16, 2025

kinke Feb 15, 2025

liushuyu Feb 15, 2025

kinke Feb 15, 2025

liushuyu Feb 15, 2025

kinke Feb 16, 2025

liushuyu Feb 16, 2025

kinke Feb 16, 2025

kinke Feb 16, 2025 •

edited

Loading

liushuyu Feb 16, 2025

liushuyu commented Feb 16, 2025

liushuyu commented Feb 16, 2025

the-horo Feb 16, 2025

kinke commented Feb 18, 2025

		@@ -570,6 +570,8 @@ version (LDC)

		version (AArch64) version = CheckFiberMigration;

		version (PPC64) version = CheckFiberMigration;

ppc64(le): Add an option to use IEEE long double ABI on Linux #4833

ppc64(le): Add an option to use IEEE long double ABI on Linux #4833

Conversation

liushuyu commented Feb 1, 2025

liushuyu commented Feb 1, 2025 • edited Loading

JohanEngelen commented Feb 2, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JohanEngelen commented Feb 2, 2025

liushuyu commented Feb 2, 2025

liushuyu commented Feb 4, 2025

liushuyu commented Feb 6, 2025

liushuyu commented Feb 15, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kinke Feb 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kinke Feb 16, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

liushuyu commented Feb 16, 2025

liushuyu commented Feb 16, 2025

Choose a reason for hiding this comment

kinke commented Feb 18, 2025

liushuyu commented Feb 1, 2025 •

edited

Loading

kinke Feb 15, 2025 •

edited

Loading

kinke Feb 16, 2025 •

edited

Loading