@@ -16534,7 +16534,7 @@ ExprResult Sema::BuildVAArgExpr(SourceLocation
BuiltinLoc,
PromoteType = QualType();
}
}
-if (TInfo->getType()->isSpecificBuiltinType(BuiltinType::Float))
+if (TInfo->getType()->isFloat16Type() || TInfo->getType()->isFloat32T
@@ -1597,6 +1618,15 @@ bool SystemZTargetLowering::splitValueIntoRegisterParts(
return true;
}
+ // Convert f16 to f32 (Out-arg).
+ if (PartVT == MVT::f16) {
+assert(NumParts == 1 && "");
+SDValue I16Val = DAG.getBitcast(MVT::i16, Val);
+SDValue I32Val = DA
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -1597,6 +1618,15 @@ bool SystemZTargetLowering::splitValueIntoRegisterParts(
return true;
}
+ // Convert f16 to f32 (Out-arg).
+ if (PartVT == MVT::f16) {
+assert(NumParts == 1 && "");
+SDValue I16Val = DAG.getBitcast(MVT::i16, Val);
+SDValue I32Val = DA
@@ -711,6 +711,13 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
setOperationAction(ISD::BITCAST, MVT::f32, Custom);
}
+ // Expand FP16 <=> FP32 conversions to libcalls and handle FP16 loads and
+ // stores in GPRs.
+ setOperationAction(ISD:
@@ -1612,6 +1642,18 @@ SDValue
SystemZTargetLowering::joinRegisterPartsIntoValue(
return SDValue();
}
+// F32Val holds a f16 value in f32, return it as an f16 (In-arg). The
+// CopyFromReg was made into an f32 as required as FP32 registers are used
+// for arguments, now co
@@ -16534,7 +16534,7 @@ ExprResult Sema::BuildVAArgExpr(SourceLocation
BuiltinLoc,
PromoteType = QualType();
}
}
-if (TInfo->getType()->isSpecificBuiltinType(BuiltinType::Float))
+if (TInfo->getType()->isFloat16Type() || TInfo->getType()->isFloat32T
tgross35 wrote:
> From what I can see in the libgcc sources, `__gnu_h2f_ieee`/`__gnu_f2h_ieee`
> is indeed always `i32`<->`i16`, but it is only present on 32-bit ARM, no
> other platforms. On AArch64, GCC will always use inline instructions to
> perform the conversion. On 32-bit and 64-bit Int
uweigand wrote:
> My understanding is that in GCC's `__gnu_h2f_ieee`/`__gnu_f2h_ieee` is always
> `i32`<->`i16` (integer ABI), then `__extendhfsf2`/`__truncsfhf2` uses either
> `int16_t` or `_Float16` on a per-target basis as controlled by
> `__LIBGCC_HAS_HF_MODE__` (I don't know where this g
tgross35 wrote:
> With this version, the fp16 values are passed to conversion functions as
> integer, which seems to be the default. It is however a bit tricky to do this
> and at the same time pass half values in FP registers.
>
> At this point I wonder for one thing if it would be better to p
@@ -784,6 +791,20 @@ bool SystemZTargetLowering::useSoftFloat() const {
return Subtarget.hasSoftFloat();
}
+MVT SystemZTargetLowering::getRegisterTypeForCallingConv(
+ LLVMContext &Context, CallingConv::ID CC,
+ EVT VT) const {
+ // 128-bit single-element vector t
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -784,6 +791,20 @@ bool SystemZTargetLowering::useSoftFloat() const {
return Subtarget.hasSoftFloat();
}
+MVT SystemZTargetLowering::getRegisterTypeForCallingConv(
+ LLVMContext &Context, CallingConv::ID CC,
+ EVT VT) const {
+ // 128-bit single-element vector t
@@ -1597,6 +1618,15 @@ bool SystemZTargetLowering::splitValueIntoRegisterParts(
return true;
}
+ // Convert f16 to f32 (Out-arg).
+ if (PartVT == MVT::f16) {
+assert(NumParts == 1 && "");
arsenm wrote:
Remove && "" or make it a meaningful message
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu \
+// RUN: -ffloat16-excess-precision=standard -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=STANDARD
+
+// RUN: %clang_cc1 -triple s390x-linux-gnu \
+// RUN: -ffloat16-excess-precision=none -emit-llvm -o -
@@ -784,6 +791,20 @@ bool SystemZTargetLowering::useSoftFloat() const {
return Subtarget.hasSoftFloat();
}
+MVT SystemZTargetLowering::getRegisterTypeForCallingConv(
+ LLVMContext &Context, CallingConv::ID CC,
+ EVT VT) const {
+ // 128-bit single-element vector t
JonPsson1 wrote:
Patch updated after some progress...
With this version, the fp16 values are passed to conversion functions as
integer, which seems to be the default. It is however a bit tricky to do this
and at the same time pass half values in FP registers.
At this point I wonder for one th
uweigand wrote:
I think we should define and implement a proper ABI for the half type as well.
https://github.com/llvm/llvm-project/pull/109164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
JonPsson1 wrote:
> Note that you need to also have softPromoteHalfType return true to get
> correct legalization for half operations.
Thanks for pointing that out - patch updated.
https://github.com/llvm/llvm-project/pull/109164
___
cfe-commits maili
https://github.com/JonPsson1 updated
https://github.com/llvm/llvm-project/pull/109164
>From c70d421c42417a3f1a266907ef36057e51183d97 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson
Date: Tue, 17 Sep 2024 19:34:34 +0200
Subject: [PATCH] Initial experiments
---
clang/lib/Basic/Targets/SystemZ.h
nikic wrote:
Note that you need to also have softPromoteHalfType return true to get correct
legalization for half operations.
https://github.com/llvm/llvm-project/pull/109164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 8411214c56eb3f9fb77fe3a9f156d4e6ef6cec06
e0bb2adac31f9bec6fa1521a5f9fd67ce7442e14 --e
llvmbot wrote:
@llvm/pr-subscribers-backend-systemz
Author: Jonas Paulsson (JonPsson1)
Changes
Make sure that fp16<=>float conversions are expanded to libcalls and that
16-bit fp values can be loaded and stored properly via GPRs. With this patch
the Half IR Type used in operations should
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Jonas Paulsson (JonPsson1)
Changes
Make sure that fp16<=>float conversions are expanded to libcalls and that
16-bit fp values can be loaded and stored properly via GPRs. With this patch
the Half IR Type used in operations should be handle
https://github.com/JonPsson1 created
https://github.com/llvm/llvm-project/pull/109164
Make sure that fp16<=>float conversions are expanded to libcalls and that
16-bit fp values can be loaded and stored properly via GPRs. With this patch
the Half IR Type used in operations should be handled cor
27 matches
Mail list logo
