uweigand added a comment.
> This patch has been reworked, and aims to specify which features systemz
> builtins require. The way of doing this has been taken from the X86 Target
> (with a '#define TARGET_BUILTIN')
>
> If a builtin is used by the programmer for a target that does not include a
uweigand added a comment.
I don't think we actually need the builtins-systemz-z13.c test, it only
duplicates tests already done by builtins-systemz.c and
builtins-systemz-vector.c. (Note that those tests implicitly verify that there
is no compiler error by checking the compiler exit code.)
Al
uweigand added a comment.
Makes sense to me.
http://reviews.llvm.org/D18998
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
uweigand added a subscriber: uweigand.
uweigand added a comment.
Now that our build bot is up and running again, I noticed that the newly added
test pipe_types.cl fails on SystemZ:
/home3/uweigand/llvm/llvm-head/tools/clang/test/CodeGenOpenCL/pipe_types.cl:26:11:
error: expected string not f
uweigand added a comment.
In http://reviews.llvm.org/D15603#338488, @Anastasia wrote:
> No, this shouldn't happen! There shouldn't be any difference in emitted IR
> depending on a platform. I also don't see any code in CodeGen that could
> specialize.
>
> Is there a way to reproduce your compil
Author: uweigand
Date: Fri Jan 29 04:45:23 2016
New Revision: 259183
URL: http://llvm.org/viewvc/llvm-project?rev=259183&view=rev
Log:
Add target triple to CodeGenOpenCL/pipe_types.cl test case
The test is failing on SystemZ since different IR is being
generated due to platform ABI differences.
uweigand added a comment.
In http://reviews.llvm.org/D15603#338593, @Anastasia wrote:
> Yes, I see that it happens only for some vector types. The CodeGen follows
> quite different paths for both targets. And in the case of s390x-linux-gnu it
> ends up in ABIArgInfo::Indirect case of the second
uweigand wrote:
This `/etc/lsb-release` test looks a bit weird to me. Why can't it simply do:
```
echo ${UNAME_MACHINE}-ibm-linux-${LIBC}
```
like the upstream `config.guess` does?
That should properly match the other variants that are simply missing one of
the triple fields.
https:/
uweigand wrote:
For SystemZ the correct value is 256. In general I agree it makes sense to
look at the GCC implementation as a source of reasonable values. Also, I
think there probably should be no generic default value at all - it there is no
platform-specific value known, it seems better
uweigand wrote:
> > For SystemZ the correct value is 256.
>
> Thanks! Double-checking: for both constructive and destructive?
Yes, for both. Every SystemZ model (supported by GCC/LLVM) has a L1 cache line
size of 256 bytes.
> > In general I agree it makes sense to look at the GCC implementat
https://github.com/uweigand approved this pull request.
LGTM now, thanks!
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -529,9 +530,355 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
https://github.com/uweigand edited
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -529,9 +530,355 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
https://github.com/uweigand commented:
This version LGTM now, I think once the transparent-union thing is resolved,
this should be ready to commit. Thanks!
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists
Author: Ulrich Weigand
Date: 2024-07-18T17:43:28+02:00
New Revision: 9af3628ce7400a96205a4c4468867c3c11dd4b2f
URL:
https://github.com/llvm/llvm-project/commit/9af3628ce7400a96205a4c4468867c3c11dd4b2f
DIFF:
https://github.com/llvm/llvm-project/commit/9af3628ce7400a96205a4c4468867c3c11dd4b2f.diff
uweigand wrote:
Turns out transparent union handling was indeed broken in the SystemZ ELF ABI
as well. I've now checked in a fix here:
https://github.com/llvm/llvm-project/commit/9af3628ce7400a96205a4c4468867c3c11dd4b2f
https://github.com/llvm/llvm-project/pull/91384
_
https://github.com/uweigand created
https://github.com/llvm/llvm-project/pull/90467
The AltiVec (POWER) and ZVector (IBM Z) language extensions do not support
using the "vector" keyword when the element type is a complex type, but current
code does not verify this.
Add a Sema check and diagno
https://github.com/uweigand updated
https://github.com/llvm/llvm-project/pull/90467
>From 7f13179745ccc31ceca223c03c6b75fa46b4fe37 Mon Sep 17 00:00:00 2001
From: Ulrich Weigand
Date: Mon, 29 Apr 2024 15:04:31 +0200
Subject: [PATCH] [Clang][Sema] Do not accept "vector _Complex" for
AltiVec/ZVec
@@ -1191,6 +1191,10 @@ void DeclSpec::Finish(Sema &S, const PrintingPolicy
&Policy) {
// Validate and finalize AltiVec vector declspec.
if (TypeAltiVecVector) {
+// Complex vector types are not supported.
+if (TypeSpecComplex != TSC_unspecified)
+ S.Diag(TSCL
https://github.com/uweigand closed
https://github.com/llvm/llvm-project/pull/90467
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/uweigand edited
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -529,9 +530,355 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
https://github.com/uweigand commented:
This version looks mostly good to me - just a few remaining questions inline.
Thanks!
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
@@ -529,9 +530,355 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,355 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -triple s390x-ibm-zos \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple s390x-ibm-zos -target-feature +vector \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// R
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,324 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -triple s390x-ibm-zos \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple s390x-ibm-zos -target-feature +vector \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// R
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +530,401 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -triple s390x-ibm-zos \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple s390x-ibm-zos -target-feature +vector \
+// RUN: -emit-llvm -no-enable-noundef-analysis -o - %s | FileCheck %s
+// R
uweigand wrote:
I'm not seeing any failures with this patch on s390x with the regular check-all
and check-openmp tests. Do you have a link to the failures you were seeing in
the past (was that on the build bot?)?
https://github.com/llvm/llvm-project/pull/92353
https://github.com/uweigand commented:
See comment fix - otherwise SystemZ part LGTM.
https://github.com/llvm/llvm-project/pull/93179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/uweigand edited
https://github.com/llvm/llvm-project/pull/93179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,94 @@
+//===-- SemaSystemZ.cpp -- SystemZ target-specific routines
---===//
+//
+// 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
https://github.com/uweigand requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/101024
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -532,9 +532,371 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -532,9 +532,371 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
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
@@ -16534,7 +16534,7 @@ ExprResult Sema::BuildVAArgExpr(SourceLocation
BuiltinLoc,
PromoteType = QualType();
}
}
-if (TInfo->getType()->isSpecificBuiltinType(BuiltinType::Float))
+if (TInfo->getType()->isFloat16Type() || TInfo->getType()->isFloat32T
@@ -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
@@ -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:
@@ -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
uweigand wrote:
Looks like the new test case is failing on SystemZ:
https://lab.llvm.org/buildbot/#/builders/42/builds/1192
```
struct.error: unpack_from requires a buffer of at least 402653196 bytes for
unpacking 12 bytes at offset 402653184 (actual buffer size is 479)
```
At first glance, thi
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-
uweigand wrote:
SystemZ changes LGTM.
https://github.com/llvm/llvm-project/pull/109160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Ulrich Weigand
Date: 2024-09-19T13:19:03+02:00
New Revision: baf9b7da81025c1e3b0704d7ecf667e06f95642b
URL:
https://github.com/llvm/llvm-project/commit/baf9b7da81025c1e3b0704d7ecf667e06f95642b
DIFF:
https://github.com/llvm/llvm-project/commit/baf9b7da81025c1e3b0704d7ecf667e06f95642b.diff
uweigand wrote:
LGTM as well, thanks.
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
@@ -532,9 +532,371 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
uweigand wrote:
Hi @anoopkg6 , the tests are still failing in CI because this is hosted on an
Intel machine, so when you run just with `llc`, it will attempt to build the
test for Intel ...
To make sure the tests run correctly and always target s390x, you should use
something along the follow
@@ -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 ==
@@ -0,0 +1,24 @@
+;Test longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck %s
+
+@buf = dso_local global [20 x ptr] z
@@ -0,0 +1,323 @@
+; Test for Frame Pointer in first slot in jmp_buf.
uweigand wrote:
Similar question here. This is a very long test, and only a couple of
instructions are tested via CHECK statements. Whatever we want to test here
should be done in a much mo
@@ -0,0 +1,89 @@
+;Test longjmp load from jmp_buf.
uweigand wrote:
We certainly do not need to verify e.g. printf codegen here, so even if we do
need the test for some reason, it should be significantly simplified.
https://github.com/llvm/llvm-project/pull/116
@@ -0,0 +1,89 @@
+;Test longjmp load from jmp_buf.
uweigand wrote:
What is the added benefit of this combined test? This seems to have been
compiled from a C language test that would be useful to run as *execute* test
(which we cannot do here). But here we
@@ -0,0 +1,216 @@
+; Simulate register pressure around setjmp call for double precision
+; arguments and return sum of 20 vaiables. It also prints the variables.
uweigand wrote:
As this is not an executable test, I don't think the printf code-gen tests
anythin
@@ -0,0 +1,34 @@
+;Test -mbackchain longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Backchain Value from Slot 3.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck
https://github.com/uweigand commented:
Some additional comments on the test cases inline.
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
@@ -0,0 +1,24 @@
+;Test longjmp load from jmp_buf.
uweigand wrote:
Please fix the white spaces. Space after ';', only one space between words.
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing
@@ -0,0 +1,75 @@
+; Test -mbackchain setjmp store jmp_buf
uweigand wrote:
See above.
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/uweigand edited
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,145 @@
+; Simulate register pressure around setjmp call for double precision
arguments.
+; Test assembly of funtion call foo in func() in setjmp if and else part.
+; extern foo has 20 argument pointer to double precision.
+; Test setjmp store jmp_buf.
+; Return addre
@@ -0,0 +1,145 @@
+; Simulate register pressure around setjmp call for double precision
arguments.
uweigand wrote:
Register pressure may indeed be a good reason to have a longer test. Still,
the CHECK statements should be auto-generated. Also, even here we s
@@ -0,0 +1,24 @@
+;Test longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck %s
+
+@buf = dso_local global [20 x ptr] z
@@ -0,0 +1,146 @@
+; -mbackchain option.
uweigand wrote:
Also, I don't think we need -mbackchain versions of all of those. We have the
simple tests above that verify -mbackchain works, we don't need to repeat this
for all other tests.
https://github.com/llvm
@@ -0,0 +1,47 @@
+; Test setjmp store jmp_buf
uweigand wrote:
Most of the above longjmp comments apply likewise to the setjmp tests.
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing list
cfe-co
@@ -0,0 +1,24 @@
+;Test longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck %s
+
+@buf = dso_local global [20 x ptr] z
@@ -0,0 +1,145 @@
+; Simulate register pressure around setjmp call for double precision
arguments.
uweigand wrote:
There doesn't seem to be a -01 test with this name, please rename to remove
those gaps.
https://github.com/llvm/llvm-project/pull/116642
___
@@ -0,0 +1,47 @@
+; Test setjmp store jmp_buf
+; Return address in slot 2.
+; Stack Pointer in slot 4.
+; Clobber %r6-%r15, %f8-%f15.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O3 | FileCheck %s
+
+@buf = dso_local global [20 x ptr] zeroinitializer, align 8
+
+; Function Attrs
@@ -0,0 +1,215 @@
+; Simulate register pressure around setjmp call for integer arguments and
+; return sum of 20 vaiables. It also prints the variables.
uweigand wrote:
See above comments on the -double tests.
https://github.com/llvm/llvm-project/pull/116642
_
@@ -0,0 +1,24 @@
+;Test longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck %s
+
+@buf = dso_local global [20 x ptr] z
@@ -0,0 +1,145 @@
+; Simulate register pressure around setjmp call for double precision
arguments.
+; Test assembly of funtion call foo in func() in setjmp if and else part.
+; extern foo has 20 argument pointer to double precision.
+; Test setjmp store jmp_buf.
+; Return addre
@@ -0,0 +1,34 @@
+;Test -mbackchain longjmp load from jmp_buf.
+; Frame pointer from Slot 1.
+; Jump address from Slot 2.
+; Backchain Value from Slot 3.
+; Stack Pointer from Slot 4.
+; Literal Pool Pointer from Slot 5.
+
+; RUN: llc < %s -mtriple=s390x-linux-gnu -O2 | FileCheck
@@ -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 ==
@@ -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:
uweiga
@@ -940,7 +947,242 @@ bool SystemZTargetLowering::isFPImmLegal(const APFloat
&Imm, EVT VT,
return SystemZVectorConstantInfo(Imm).isVectorConstantLegal(Subtarget);
}
-/// Returns true if stack probing through inline assembly is requested.
+
+MachineBasicBlock *
+SystemZTarge
@@ -4619,6 +4619,12 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
// Buffer is a void**.
Address Buf = EmitPointerWithAlignment(E->getArg(0));
+if (getTarget().getTriple().getArch() == llvm::Triple::systemz) {
+ // Call L
@@ -940,7 +947,242 @@ bool SystemZTargetLowering::isFPImmLegal(const APFloat
&Imm, EVT VT,
return SystemZVectorConstantInfo(Imm).isVectorConstantLegal(Subtarget);
}
-/// Returns true if stack probing through inline assembly is requested.
+
+MachineBasicBlock *
+SystemZTarge
https://github.com/uweigand commented:
Thanks for the contribution! Please find a number of comments inline. Also,
you should address the issues found by the CI, e.g. about coding style.
https://github.com/llvm/llvm-project/pull/116642
___
cfe-comm
@@ -4619,6 +4619,12 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
// Buffer is a void**.
Address Buf = EmitPointerWithAlignment(E->getArg(0));
+if (getTarget().getTriple().getArch() == llvm::Triple::systemz) {
+ // Call L
@@ -0,0 +1,72 @@
+; Test output of setjmp/longjmp.
+; RUN: clang -o %t %s
+; RUN: %t | FileCheck %s
uweigand wrote:
Ah. This is a problem. The unit tests here cannot be execution tests;
they'll have to run on any host system (e.g. on the automated CI on GitHu
https://github.com/uweigand edited
https://github.com/llvm/llvm-project/pull/116642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/uweigand commented:
Not a full review, but some general comments inline.
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-com
@@ -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
@@ -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
@@ -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
@@ -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
101 - 200 of 363 matches
Mail list logo
