[clang][AArch64] Enable fp128 for aarch64 linux target

[MDevereau]

No description provided.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Matthew Devereau (MDevereau)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/85070.diff

2 Files Affected:

• (modified) clang/lib/Basic/Targets/OSTargets.h (+1)
• (modified) clang/test/CodeGenCXX/float128-declarations.cpp (+24)

diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/OSTargets.h
index 4366c1149e4053..ba92604b9bcb9a 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -359,6 +359,7 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public OSTargetInfo<Target> {
       break;
     case llvm::Triple::x86:
     case llvm::Triple::x86_64:
+    case llvm::Triple::aarch64:
       this->HasFloat128 = true;
       break;
     }
diff --git a/clang/test/CodeGenCXX/float128-declarations.cpp b/clang/test/CodeGenCXX/float128-declarations.cpp
index 84b8f7f33036b5..79c99ba2796126 100644
--- a/clang/test/CodeGenCXX/float128-declarations.cpp
+++ b/clang/test/CodeGenCXX/float128-declarations.cpp
@@ -26,6 +26,8 @@
 // RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86
 // RUN: %clang_cc1 -emit-llvm -triple x86_64-unknown-haiku -std=c++11 \
 // RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86
+// RUN: %clang_cc1 -emit-llvm -triple aarch64-linux-gnu -std=c++11 \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-AARCH64-DAG
 //
 /*  Various contexts where type __float128 can appear. The different check
     prefixes are due to different mangling on X86.  */
@@ -131,3 +133,25 @@ int main(void) {
 // CHECK-X86-DAG: [[F4L:%[a-z0-9]+]] = load fp128, ptr %f4l
 // CHECK-X86-DAG: [[INC:%[a-z0-9]+]] = fadd fp128 [[F4L]], 0xL00000000000000003FFF000000000000
 // CHECK-X86-DAG: store fp128 [[INC]], ptr %f4l
+
+// CHECK-AARCH64-DAG: @f1f ={{.*}} global fp128 0xL00000000000000000000000000000000
+// CHECK-AARCH64-DAG: @f2f ={{.*}} global fp128 0xL33333333333333334004033333333333
+// CHECK-AARCH64-DAG: @arr1f ={{.*}} global [10 x fp128]
+// CHECK-AARCH64-DAG: @arr2f ={{.*}} global [3 x fp128] [fp128 0xL3333333333333333BFFF333333333333, fp128 0xL0000000000000000C000800000000000, fp128 0xL0000000000000000C025176592E00000]
+// CHECK-AARCH64-DAG: @__const.main.s1 = private unnamed_addr constant %struct.S1 { fp128 0xL00000000000000004006080000000000 }
+// CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_13f1nE = internal global fp128 0xL00000000000000000000000000000000
+// CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_13f2nE = internal global fp128 0xL00000000000000004004080000000000
+// CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_15arr1nE = internal global [10 x fp128]
+// CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_15arr2nE = internal global [3 x fp128] [fp128 0xL33333333333333333FFF333333333333, fp128 0xL00000000000000004000800000000000, fp128 0xL00000000000000004025176592E00000]
+// CHECK-AARCH64-DAG: store fp128 0xLF0AFD0EBFF292DCE42E0B38CDD83F26F, ptr %f1l, align 16
+// CHECK-AARCH64-DAG: store fp128 0xL00000000000000008000000000000000, ptr %f2l, align 16
+// CHECK-AARCH64-DAG: store fp128 0xLFFFFFFFFFFFFFFFF7FFEFFFFFFFFFFFF, ptr %f3l, align 16
+// CHECK-AARCH64-DAG: store fp128 0xL0000000000000000BFFF000000000000, ptr %f5l, align 16
+// CHECK-AARCH64-DAG: [[F4L:%[a-z0-9]+]] = load fp128, ptr %f4l
+// CHECK-AARCH64-DAG: [[INC:%[a-z0-9]+]] = fadd fp128 [[F4L]], 0xL00000000000000003FFF000000000000
+// CHECK-AARCH64-DAG: store fp128 [[INC]], ptr %f4l
+// CHECK-AARCH64-DAG: define internal noundef fp128 @_ZN12_GLOBAL__N_16func1nERKg(ptr
+// CHECK-AARCH64-DAG: declare noundef fp128 @_Z6func1fg(fp128 noundef)
+// CHECK-AARCH64-DAG: define linkonce_odr noundef fp128 @_ZN2C16func2cEg(fp128 noundef %arg)
+// CHECK-AARCH64-DAG: define linkonce_odr noundef fp128 @_Z6func1tIgET_S0_(fp128 noundef %arg)
+// CHECK-AARCH64-DAG: define linkonce_odr void @_ZN2C1C2Eg(ptr {{[^,]*}} %this, fp128 noundef %arg)

[davemgreen]

Hi - I think this looks sensible, considering that long double == fp128. Should we be doing the same for other OS's in this file too?

[efriedma-quic]

See also #80195 (CC @nickdesaulniers).

gcc on aarch64 Linux only supports _Float128, not __float128; this seems like a bit of a compatibility hazard.

[nickdesaulniers]

Right, I'm more interested in being able to use on aarch64 the _Float128 type as standardized by C23, than the clang specific __float128 extension. Does this PR help get us there?

EDIT: in fact, if we could skip propagating the clang-specific extension further, and just go straight to C23 _Float128, I'd prefer that.

[lntue]

Right, I'm more interested in being able to use on aarch64 the _Float128 type as standardized by C23, than the clang specific __float128 extension. Does this PR help get us there?

EDIT: in fact, if we could skip propagating the clang-specific extension further, and just go straight to C23 _Float128, I'd prefer that.

I would second that we should go straight to C23 _Float128. The current landscape for float128 supports in C (clang / gcc) and C++ (clang++, g++) : #78017 (comment)
So adding __float128 to aarch64 does not help much to simplify codes that need to work for both clang & gcc.

I haven't tested but I think the picture for float128 on riscv would be similar to aarch64.

[pranavk]

I have same opinion as @lntue and Nick.