JonPsson1 wrote:
libcalls emission:
For the uint->fp, SelectionDAGLegalize::ExpandLegalINT_TO_FP() has an assertion
before the last attempt involving converting to SINT_TO_FP, that makes sure
that this optimization is possible. If I change that to return SDValue()
instead of asserting, these
@@ -126,3 +138,23 @@ define void @f9(ptr %cptr, ptr %aptr, ptr %bptr) {
store fp128 %c, ptr %cptr
ret void
}
+
+; Test f16 copies in which the sign comes from an f16.
+define half @f10(half %a, half %b) {
+; CHECK-LABEL: f10:
+; CHECK: brasl %r14, copysignh@PLT
@@ -3,6 +3,18 @@
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z10 | FileCheck %s
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 | FileCheck %s
+; Test f16.
+declare half @llvm.fabs.f16(half %f)
+define half @f0(half %f) {
+; CHECK-LABEL: f0:
+; CHECK: brasl %r14, __
@@ -0,0 +1,65 @@
+; Test copysign intrinsics involving half.
+;
+; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s
+
+declare half @llvm.copysign.f16(half, half)
+declare float @llvm.copysign.f32(float, float)
+declare double @llvm.copysign.f64(double, double)
+
+; Test f16
JonPsson1 wrote:
> This is about whether we can (and should) implement a fp->u32 conversion via
> fp->s64->u32.
Thanks for explaining - I updated the comment just a little bit so it is - at
least to me - a bit easier to follow.
> I see that the LowerOperationWrapper still emits i128 operation
JonPsson1 wrote:
Thanks to @boomanaiden154 for pointing out that I need to pass
-DCOMPILER_RT_BUILD_BUILTINS=ON to cmake - the tests now builds and runs.
The test for half->double conversions added, with the 64-bit hex values taken
from the compiler-rt conversion function results (should be co
@@ -126,3 +138,23 @@ define void @f9(ptr %cptr, ptr %aptr, ptr %bptr) {
store fp128 %c, ptr %cptr
ret void
}
+
+; Test f16 copies in which the sign comes from an f16.
+define half @f10(half %a, half %b) {
+; CHECK-LABEL: f10:
+; CHECK: brasl %r14, copysignh@PLT
JonPsson1 wrote:
Updated per review.
- Custom handlings added to deal with non-existing library functions:
FP_TO_INT:
Z10 unsigned:
Expanding fp-> i32/i64 seems to work best to do without first doing the custom
extension to f32 in the f16 input case. TargetLowering::expandFP_TO_UINT() can
@@ -87,6 +90,15 @@ define <2 x double> @f7(<2 x double> %dummy, <2 x double>
%val1,
ret <2 x double> %ret
}
+; Test the fminh library function.
+define half @f11_half(half %dummy, half %val1, half %val2) {
+; CHECK-LABEL: f11_half:
+; CHECK: %r14, fminh@PLT
@@ -0,0 +1,65 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=zEC12 -verify-machineinstrs \
+; RUN: | FileCheck %s --check-prefix=NOVEC
+; RUN: llc < %s -mtriple=s390x-linux-
@@ -0,0 +1,63 @@
+# RUN: llc -o - %s -mtriple=s390x-linux-gnu -mcpu=zEC12 -verify-machineinstrs \
+# RUN: -start-before=greedy | FileCheck %s -check-prefix=CHECK
+# RUN: llc -o - %s -mtriple=s390x-linux-gnu -mcpu=z16 -verify-machineinstrs \
+# RUN: -start-before=greedy | FileC
JonPsson1 wrote:
Patch rebased.
The reported formatting issue here is in the test which however was mostly
copied from a pre-existing test, so maybe clang-format should be done on all
these tests or not. Skipping it for now.
https://github.com/llvm/llvm-project/pull/109164
___
@@ -548,11 +543,28 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ if (!useSoftFloat()) {
+// Promote all f16 operations to float, with some exceptions below.
+for (unsigned Opc = 0; Opc < ISD::BUILTIN_
JonPsson1 wrote:
Have nothing more to do for this now, so waiting for review.
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-commits
@@ -548,11 +543,28 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ if (!useSoftFloat()) {
+// Promote all f16 operations to float, with some exceptions below.
+for (unsigned Opc = 0; Opc < ISD::BUILTIN_
@@ -548,11 +543,28 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ if (!useSoftFloat()) {
+// Promote all f16 operations to float, with some exceptions below.
+for (unsigned Opc = 0; Opc < ISD::BUILTIN_
JonPsson1 wrote:
@Meinersbur @petrhosek @smeenai @danliew-apple
Reaching out here to some people who seem to have been working with this CMake
file: Would you have any idea how I could activate and run the compiler-rt
tests for s390x (see above for my unsuccessful experiments)? Thanks.
https
JonPsson1 wrote:
-- A few more tests added covering
alloca
access into aggregate type with half elements with getelementptr.
atomicrmw
Would a test for { half, half, half, half } in Swift-return.ll make sense?
I think testing coverage now is fairly ok - can't think of any more
instructions to
JonPsson1 wrote:
>
> If this is not set, you need to figure out why it is not using the correct
> host compiler. I think it should be using the clang built from the same
> sources, which _should_ now support `_Float16` - if it doesn't, this may
> cause other problems, potentially even explain
@@ -0,0 +1,27 @@
+//===-- lib/extendhfdf2.c - half -> single conversion -*- C
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
JonPsson1 wrote:
> To clarify, the code is calling `__extendhfdf2` then `__truncdfhf2` from
> either libgcc or from compiler-rt with your patches, and the compiler-rt
> version is incorrect? Could you have it print the intermediate results as u16
> hex (`Op0 + Op1`, `Res2`, `Res`)?
Yes, my te
JonPsson1 wrote:
Thanks for the help.
- new file extendhfdf2.c (and added to GENERIC_SOURCES list)
- $GENERIC_TF_SOURCES added to s390x_SOURCES. This did not work immediately.
However, if I removed the check for COMPILER_RT_HAS_FLOAT16 in the source
files, it builds. Not sure why/if that is n
JonPsson1 wrote:
> Does s390x have +soft-float or any features that toggle the availability of
> float conversion ops?
Yes, we support soft-float, and as I wrote earlier I am worried what happens
with soft-float and conversion functions. I saw that with soft-float, the same
conversion functi
JonPsson1 wrote:
Patch rebased as the handling of libcalls had changed on main.
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-commits
@@ -255,4 +255,9 @@ void RuntimeLibcallsInfo::initLibcalls(const Triple &TT) {
}
setLibcallName(RTLIB::MULO_I128, nullptr);
}
+
+ if (TT.isSystemZ()) {
+setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");
+setLibcallName(RTLIB::FPEXT_F16_F32, "__extendhfs
@@ -255,4 +255,9 @@ void RuntimeLibcallsInfo::initLibcalls(const Triple &TT) {
}
setLibcallName(RTLIB::MULO_I128, nullptr);
}
+
+ if (TT.isSystemZ()) {
+setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");
+setLibcallName(RTLIB::FPEXT_F16_F32, "__extendhfs
JonPsson1 wrote:
Found one intrinsic that isn't working for f16:
- Isel fails:
%res = call i32 @llvm.s390.tdc.f16(half %x, i64 123)
LLVM ERROR: Cannot select: t9: i32 = SystemZISD::TDC t2, Constant:i64<123>
- The SystemZTDC pass seems to work with 'half', but no tests.
- The Clang testFPKind d
@@ -3830,6 +3876,14 @@ SDValue SystemZTargetLowering::lowerSELECT_CC(SDValue Op,
ISD::CondCode CC = cast(Op.getOperand(4))->get();
SDLoc DL(Op);
+ // SELECT_CC involving f16 will not have the cmp-ops promoted by the
+ // legalizer, as it will be handled according to the
@@ -6470,6 +6540,84 @@ static SDValue lowerAddrSpaceCast(SDValue Op,
SelectionDAG &DAG) {
return Op;
}
+SDValue SystemZTargetLowering::lowerFP_EXTEND(SDValue Op,
+ SelectionDAG &DAG) const {
+ SDValue In = Op.getOperand(Op->isSt
JonPsson1 wrote:
Updated per review.
- Wrapping all isel handlings of FP with !useSoftFloat to make sure no custom
lowerering may ever use an FP reg. I am not really sure this is needed as the
type-legalizer is run before any lowering, but maybe do it just to be sure.
- Also found out that a
@@ -6769,11 +6898,20 @@ SystemZTargetLowering::LowerOperationWrapper(SDNode *N,
break;
}
case ISD::BITCAST: {
+SDLoc DL(N);
SDValue Src = N->getOperand(0);
-if (N->getValueType(0) == MVT::i128 && Src.getValueType() == MVT::f128 &&
-!useSoftFloat())
@@ -6769,11 +6898,20 @@ SystemZTargetLowering::LowerOperationWrapper(SDNode *N,
break;
}
case ISD::BITCAST: {
+SDLoc DL(N);
SDValue Src = N->getOperand(0);
-if (N->getValueType(0) == MVT::i128 && Src.getValueType() == MVT::f128 &&
-!useSoftFloat())
@@ -6464,6 +6522,70 @@ static SDValue lowerAddrSpaceCast(SDValue Op,
SelectionDAG &DAG) {
return Op;
}
+SDValue SystemZTargetLowering::lowerFP_EXTEND(SDValue Op,
+ SelectionDAG &DAG) const {
+ SDValue In = Op.getOperand(Op->isSt
@@ -6464,6 +6522,70 @@ static SDValue lowerAddrSpaceCast(SDValue Op,
SelectionDAG &DAG) {
return Op;
}
+SDValue SystemZTargetLowering::lowerFP_EXTEND(SDValue Op,
+ SelectionDAG &DAG) const {
+ SDValue In = Op.getOperand(Op->isSt
@@ -541,11 +543,26 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ // Promote all f16 operations to float, with some exceptions below.
+ for (unsigned Opc = 0; Opc < ISD::BUILTIN_OP_END; ++Opc)
+setOperati
@@ -179,20 +179,31 @@ bool SystemZABIInfo::isVectorArgumentType(QualType Ty)
const {
getContext().getTypeSize(Ty) <= 128);
}
-bool SystemZABIInfo::isFPArgumentType(QualType Ty) const {
+// The Size argument will in case of af an overaligned single element struct
+//
@@ -35,100 +35,96 @@ using namespace llvm;
#include "SystemZGenRegisterInfo.inc"
const unsigned SystemZMC::GR32Regs[16] = {
- SystemZ::R0L, SystemZ::R1L, SystemZ::R2L, SystemZ::R3L,
- SystemZ::R4L, SystemZ::R5L, SystemZ::R6L, SystemZ::R7L,
- SystemZ::R8L, SystemZ::R9L, Syst
@@ -229,7 +229,7 @@ class TargetInfo : public TransferrableTargetInfo,
bool NoAsmVariants; // True if {|} are normal characters.
bool HasLegalHalfType; // True if the backend supports operations on the half
// LLVM IR type.
- bool HalfArgsAndRetur
@@ -65,6 +65,7 @@ void __clear_cache(void *start, void *end) {
#elif defined(_WIN32) && (defined(__arm__) || defined(__aarch64__))
FlushInstructionCache(GetCurrentProcess(), start, end - start);
#elif defined(__arm__) && !defined(__APPLE__)
+#elif defined(__s390__)
--
JonPsson1 wrote:
> What is needed to move this forward?
The review is in progress so this should hopefully land quite soon.
https://github.com/llvm/llvm-project/pull/109164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
JonPsson1 wrote:
rebase
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-commits
JonPsson1 wrote:
> Both clear_cache and enable_execute_stack should just be empty no-op
> functions on our platform.
ah - ok. I fixed clear_cache.c, and this also took care of the other test case
which was calling it.
https://github.com/llvm/llvm-project/pull/109164
__
@@ -179,20 +179,31 @@ bool SystemZABIInfo::isVectorArgumentType(QualType Ty)
const {
getContext().getTypeSize(Ty) <= 128);
}
-bool SystemZABIInfo::isFPArgumentType(QualType Ty) const {
+// The Size argument will in case of af an overaligned single element struct
+//
@@ -446,10 +448,11 @@ ABIArgInfo SystemZABIInfo::classifyArgumentType(QualType
Ty) const {
// The structure is passed as an unextended integer, a float, or a double.
if (isFPArgumentType(SingleElementTy)) {
- assert(Size == 32 || Size == 64);
+ assert(Size =
JonPsson1 wrote:
Patch rebased and updated.
-- Saw two failing compiler-rt tests now:
```
Failed Tests (2):
Builtins-s390x-linux :: clear_cache_test.c
Builtins-s390x-linux :: enable_execute_stack_test.c
```
clear_cache_test.c contains a call to the compiler-rt clear_cache() function.
Fr
JonPsson1 wrote:
Thanks for help - I think I found the way to enable the building of these
functions - patch updated.
I could now (for the first time? :D ) compile and run a program on SystemZ with
_Float16 variables, by using `--rtlib=compiler-rt `with clang.
As I am not the expert on FP sem
@@ -446,10 +448,11 @@ ABIArgInfo SystemZABIInfo::classifyArgumentType(QualType
Ty) const {
// The structure is passed as an unextended integer, a float, or a double.
if (isFPArgumentType(SingleElementTy)) {
- assert(Size == 32 || Size == 64);
+ assert(Size =
JonPsson1 wrote:
> -DLLVM_RUNTIME_TARGETS
Thanks. If I use cmake with -DLLVM_RUNTIME_TARGETS=systemz, and then rebuild,
I see one more file being built:
```
ninja
[6/6] Linking CXX shared library
lib/clang/20/lib/s390x-unknown-linux-gnu/libclang_rt.asan.so
```
However it does not seem to be
JonPsson1 wrote:
I was hoping these added lines would enable the conversion functions, but it
doesn't seem to work:
```
+ if (TT.isSystemZ()) {
+setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");
+setLibcallName(RTLIB::FPEXT_F16_F32, "__extendhfsf2");
+ }
clang -target s390x-lin
JonPsson1 wrote:
Spill f16 using float instructions into 4-byte stack slots:
- Seems to work to use a RegInfoByHwMode to reset the SpillSize for FP16 to 32
bits. By using two HwMode:s, the spill size can still be 16 bits with vector
support.
- Using new LE16/STE16 opcodes seems easier than ex
JonPsson1 wrote:
>> Without vector support, it might make sense to have load/store pseudos with
>> an extra GPR def operand, so that these loads/stores can be expanded as a
>> PostRA pseudo. Then it would only need handling in one place, but OTOH
>> having a second explicit def operand is als
@@ -1883,6 +1931,10 @@ void SystemZInstrInfo::getLoadStoreOpcodes(const
TargetRegisterClass *RC,
} else if (RC == &SystemZ::FP128BitRegClass) {
LoadOpcode = SystemZ::LX;
StoreOpcode = SystemZ::STX;
+ } else if (RC == &SystemZ::FP16BitRegClass ||
+ RC ==
@@ -1883,6 +1931,10 @@ void SystemZInstrInfo::getLoadStoreOpcodes(const
TargetRegisterClass *RC,
} else if (RC == &SystemZ::FP128BitRegClass) {
LoadOpcode = SystemZ::LX;
StoreOpcode = SystemZ::STX;
+ } else if (RC == &SystemZ::FP16BitRegClass ||
+ RC ==
JonPsson1 wrote:
Improved handling to utilize vector instructions when present. New VR16
regclass, but v8f16 *not* legal. It might make sense to have it as a legal type
and e.g. do VL;VST when moving vectors in memory, and also set all vector ops
to "Expand". Not sure how trivial that change w
@@ -513,11 +514,26 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ // Promote all f16 operations to float, with some exceptions below.
+ for (unsigned Opc = 0; Opc < ISD::BUILTIN_OP_END; ++Opc)
+setOperati
@@ -255,4 +255,9 @@ void RuntimeLibcallsInfo::initLibcalls(const Triple &TT) {
}
setLibcallName(RTLIB::MULO_I128, nullptr);
}
+
+ if (TT.isSystemZ()) {
+setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");
+setLibcallName(RTLIB::FPEXT_F16_F32, "__extendhfs
JonPsson1 wrote:
Updated per review.
- strict fp-round / fp-extend added with tests.
- math functions like fsin promoted instead of expanded to non-existing fsinh.
- conversion functions from e.g. f16 -> f64 used instead of separate steps.
- __fp16 argument/return values removed (and tests in sy
@@ -91,11 +91,28 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public
TargetInfo {
"-v128:64-a:8:16-n32:64");
}
MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 128;
+
+// True if the backend supports operations on the half LLVM IR type.
https://github.com/JonPsson1 edited
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-commits
@@ -6285,6 +6465,16 @@ SDValue SystemZTargetLowering::LowerOperation(SDValue Op,
return lowerAddrSpaceCast(Op, DAG);
case ISD::ROTL:
return lowerShift(Op, DAG, SystemZISD::VROTL_BY_SCALAR);
+ case ISD::FP_EXTEND:
+//case ISD::STRICT_FP_EXTEND:
JonPss
@@ -513,11 +514,37 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ // Promote all f16 operations to float, with some exceptions below.
+ for (unsigned Opc = 0; Opc < ISD::BUILTIN_OP_END; ++Opc)
+setOperati
@@ -6108,6 +6160,133 @@ static SDValue lowerAddrSpaceCast(SDValue Op,
SelectionDAG &DAG) {
return Op;
}
+SDValue SystemZTargetLowering::LowerFP_EXTEND(SDValue Op,
+ SelectionDAG &DAG) const {
+ bool IsStrict = Op->isStrictFPOpco
@@ -6108,6 +6160,133 @@ static SDValue lowerAddrSpaceCast(SDValue Op,
SelectionDAG &DAG) {
return Op;
}
+SDValue SystemZTargetLowering::LowerFP_EXTEND(SDValue Op,
+ SelectionDAG &DAG) const {
+ bool IsStrict = Op->isStrictFPOpco
@@ -102,6 +102,7 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
addRegisterClass(MVT::i32, &SystemZ::GR32BitRegClass);
addRegisterClass(MVT::i64, &SystemZ::GR64BitRegClass);
if (!useSoftFloat()) {
+addRegisterClass(MVT::f16, &SystemZ::FP16
https://github.com/JonPsson1 edited
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-commits
https://github.com/JonPsson1 edited
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-commits
JonPsson1 wrote:
LGTM, but maybe also update the FIXME comment in the original version of
CreateRuntimeFunction().
https://github.com/llvm/llvm-project/pull/113506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
JonPsson1 wrote:
Patch improved further:
- Atomic memops handled.
- Spill/reload
Handled in loadRegFromStackSlot() and storeRegToStackSlot(). VRegs can be
used here which
makes it straightforward, but special sequences needed (without using
VSTE/VLE).
- __fp16:
HalfArgsAndReturns=true
JonPsson1 wrote:
I will abandon this now since @efriedma-quic's patch (#113506) is the better
approach and approved.
https://github.com/llvm/llvm-project/pull/111740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/JonPsson1 closed
https://github.com/llvm/llvm-project/pull/111740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonPsson1 wrote:
What does it mean that this is a "draft"? It seems to me that this is ready for
a regular review..?
https://github.com/llvm/llvm-project/pull/113506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
@@ -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
JonPsson1 wrote:
> SetLLVMFunctionAttributes() should add the appropriate signext/zeroext
> attribute. At least, it appears to work in my testing. I'll add a regression
> test.
Ah, I see. I ran this now on SystemZ and can confirm that this is now getting
the proper extension attributes. A tes
JonPsson1 wrote:
> I looked to see how hard it would be to lower the clang type... seems like
> it's not hard. Pushed #113506. Let me know what you think.
>
> If there's some complication I'm not seeing, I think your suggested API in
> the current version of this patch makes sense... but using
JonPsson1 wrote:
It would be great if this new method also called TargetLibraryInfo and set the
extension attributes for any integer <=32 bits... Or are you maybe waiting with
that as a separate patch?
https://github.com/llvm/llvm-project/pull/113506
___
JonPsson1 wrote:
Ping!
I'd love to get this check enabled by default after fixing the issues I see...
This is the only one for Objective-C (the second one here came up after fixing
the first one).
https://github.com/llvm/llvm-project/pull/111740
__
JonPsson1 wrote:
gentle ping... @efriedma-quic @nikic
https://github.com/llvm/llvm-project/pull/111740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonPsson1 wrote:
Patch updated to pass an extension attribute for each retval/parameter, per
your suggestion.
There may possibly be cases of NoExt (struct-in-reg) that also need to be
handled, but I will wait with that until I have a test case.
Does this seem ok (for now at least), or would y
https://github.com/JonPsson1 updated
https://github.com/llvm/llvm-project/pull/111740
>From fb8b76aca00b97166e56fcaefc241850b2535f94 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson
Date: Wed, 9 Oct 2024 18:51:22 +0200
Subject: [PATCH 1/3] Add SExt attr to 2nd arg
---
clang/lib/CodeGen/CGBlocks.
https://github.com/JonPsson1 created
https://github.com/llvm/llvm-project/pull/111740
Add extension attributes in declarations of _Block_object_dispose and
_Block_object_assign.
In order to make this one-liners wherever needed, a new casting method
FunctionCallee::getAsFunction() has been add
@@ -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
https://github.com/JonPsson1 closed
https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonPsson1 wrote:
@uweigand SystemZ parts ok?
https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonPsson1 wrote:
@nikic thanks for review - patch updated.
https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonPsson1 updated
https://github.com/llvm/llvm-project/pull/100757
>From 1e7544f684579ed2016f4037a611a5939adabee9 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson
Date: Mon, 11 Oct 2021 19:08:42 +0200
Subject: [PATCH 1/3] VerifyIntegerArgs() i8 test. LangRef text. tests IP Tests
@@ -9800,3 +9817,45 @@ SDValue
SystemZTargetLowering::lowerVECREDUCE_ADD(SDValue Op,
ISD::EXTRACT_VECTOR_ELT, DL, VT, DAG.getBitcast(OpVT, Op),
DAG.getConstant(OpVT.getVectorNumElements() - 1, DL, MVT::i32));
}
+
+// Only consider a function fully internal as long
@@ -9800,3 +9817,45 @@ SDValue
SystemZTargetLowering::lowerVECREDUCE_ADD(SDValue Op,
ISD::EXTRACT_VECTOR_ELT, DL, VT, DAG.getBitcast(OpVT, Op),
DAG.getConstant(OpVT.getVectorNumElements() - 1, DL, MVT::i32));
}
+
+// Only consider a function fully internal as long
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
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
JonPsson1 wrote:
gentle ping to @nikic
https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonPsson1 wrote:
> I think the general direction is fine here. I would suggest to split this up
> into three parts: 1. Add noext attribute and disabled verification, 2. fix
> any verification failures (e.g. by emitting noext), 3. enable verification.
>
> It would be good to still be able to ena
https://github.com/JonPsson1 updated
https://github.com/llvm/llvm-project/pull/100757
>From 99116cbe7fa4ce73b7dd242052cdfd59331f5338 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson
Date: Mon, 11 Oct 2021 19:08:42 +0200
Subject: [PATCH 1/2] VerifyIntegerArgs() i8 test. LangRef text. tests IP Tests
JonPsson1 wrote:
> The JIT tests should be fixed so that they reflect what a front-end developer
> should actually emit as LLVM IR.
Do you mean this specifically for clang-repl, or all of them? Please give some
more details (following from previous discussions here and on discourse - see
link
JonPsson1 wrote:
Patch rebased. Tests failing as before:
```
Failed Tests (44):
Clang :: CodeGenObjC 1 fail
Clang :: Interpreter 15 fails
Clang-Unit :: Interpreter18 fails
LLVM-Unit :: ExecutionEngine/Orc/./
https://github.com/JonPsson1 updated
https://github.com/llvm/llvm-project/pull/100757
>From 834d8bcd0077f0691ab33983cc72697ff6e65793 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson
Date: Mon, 11 Oct 2021 19:08:42 +0200
Subject: [PATCH] VerifyIntegerArgs() i8 test. LangRef text. tests IP Tests
pa
JonPsson1 wrote:
Patch updated per @nikic suggestion to use a TargetOption flag to simply
disable this for llc.
With all the llc lit tests out of the way, I now see:
- 1 test failing in CodeGenObjC
- failing tests in clang/test/Interpreter
- failing tetss in llvm/test/ExecutionEngine/Orc/./OrcJ
@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are
defined:
value should be sign-extended to the extent required by the target's
ABI (which is usually 32-bits) by the caller (for a parameter) or
the callee (for a return value).
+``noext``
1 - 100 of 218 matches
Mail list logo
