https://github.com/uweigand closed
https://github.com/llvm/llvm-project/pull/129170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
uweigand wrote:
> I'd like if this could also make it into a clang 19 release if possible.
I don't think there will be any further clang 19 releases. It should be
backported into clang 20, however.
https://github.com/llvm/llvm-project/pull/129170
__
https://github.com/uweigand milestoned
https://github.com/llvm/llvm-project/pull/129170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
uweigand wrote:
> * However, if I removed the check for COMPILER_RT_HAS_FLOAT16 in the source
> files, it builds. Not sure why/if that is needed there (there is no check for
> it in e.g. extendhfdf2.c), or how it could be set.
This is set if the host compiler used to build compiler-rt supports
uweigand wrote:
> For the missing libfunctions, I see these files in compiler-rt/lib/builtins:
>
> ```
> compiler-rt/lib/builtins/extendhfsf2.c
> compiler-rt/lib/builtins/extendhftf2.c
> compiler-rt/lib/builtins/extendhfxf2.c
> ```
>
> For double, I get undefined reference to `__extendhfdf2' fr
uweigand wrote:
In the SystemZ tests, the variables involved have been deliberated marked
`volatile` to prevent this type of optimization (the tests are supposed to
verify the basic operation of the intrinsics). Does this new transformation
respect `volatile`?
https://github.com/llvm/llvm-pr
uweigand wrote:
/cherry-pick
https://github.com/llvm/llvm-project/commit/ddaa5b3bfb2980f79c6f277608ad33a6efe8d554
https://github.com/llvm/llvm-project/pull/129170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
uweigand wrote:
I think that compiler-rt should provide all six conversion routines (f16<->f32,
f16<->f64, f16<->f128), simply because libgcc has them and GCC-generated code
will use them, and compiler-rt is supposed to be usable as drop-in replacement.
Also, I think LLVM should ideally genera
uweigand wrote:
To clarify about soft-float - we do support `-msoft-float` as a compiler
option, but there is no actual soft-float library provided anywhere; never has
been. The compiler option is still useful in particular for the case of the
Linux kernel: kernel code does not actually have
uweigand wrote:
> So this should already work. If it doesn't, you'll have to debug the build
> process here (e.g. look at preprocessed output to see what's actually going
> on here).
Ah, sorry, now I see what's going on. In this line you added to the cmake
logic:
```
set(s390x_SOURCES ${GENE
Author: Ulrich Weigand
Date: 2025-02-14T00:10:37+01:00
New Revision: adacbf68ebeaeaf9d07a5beaff163da9ca0534a9
URL:
https://github.com/llvm/llvm-project/commit/adacbf68ebeaeaf9d07a5beaff163da9ca0534a9
DIFF:
https://github.com/llvm/llvm-project/commit/adacbf68ebeaeaf9d07a5beaff163da9ca0534a9.diff
@@ -115,10 +115,19 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public
TargetInfo {
return RegName == "r15";
}
+ // CC has interval [0, 4).
+ unsigned getFlagOutputCCUpperBound() const override { return 4; }
bool validateAsmConstraint(const char *&Name,
@@ -8132,7 +8722,9 @@ SDValue SystemZTargetLowering::combineBR_CCMASK(
SDValue Chain = N->getOperand(0);
SDValue CCReg = N->getOperand(4);
- if (combineCCMask(CCReg, CCValidVal, CCMaskVal))
+ // combineCCIPMMask tries to combine srl/ipm sequence for flag output
operand.
@@ -2837,8 +2837,37 @@ void SelectionDAGBuilder::visitBr(const BranchInst &I) {
Opcode = Instruction::And;
else if (match(BOp, m_LogicalOr(m_Value(BOp0), m_Value(BOp1
Opcode = Instruction::Or;
-
-if (Opcode &&
+auto &TLI = DAG.getTargetLoweringInfo()
@@ -1689,6 +1696,35 @@ Register
SystemZTargetLowering::getExceptionSelectorRegister(
return Subtarget.isTargetXPLINK64() ? SystemZ::R2D : SystemZ::R7D;
}
+// Lower @cc targets via setcc.
+SDValue SystemZTargetLowering::LowerAsmOutputForConstraint(
+SDValue &Chain, SDVal
@@ -115,10 +115,19 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public
TargetInfo {
return RegName == "r15";
}
+ // CC has interval [0, 4).
+ unsigned getFlagOutputCCUpperBound() const override { return 4; }
bool validateAsmConstraint(const char *&Name,
uweigand wrote:
> Moved the comment "Promoting the result to i64...so use the default
> expansion" that was present in SystemZISelLowering.cpp into this method, but
> don't quite understand it fully. Is this talking about promoting to signed
> i64?
This is about whether we can (and should) im
https://github.com/uweigand approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/141110
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
uweigand wrote:
@Endilll thanks for the heads-up! Looks like there has been some issue with
network connectivity in our test lab over the weekend. This is supposed to be
resolved now; I'll keep observing the status for a bit.
https://github.com/llvm/llvm-project/pull/140378
301 - 320 of 320 matches
Mail list logo
