wzssyqa wrote:
@nikic Thanks. I submit an RFC now
https://discourse.llvm.org/t/rfc-fix-llvm-min-f-and-llvm-max-f-intrinsics/79735
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
wzssyqa wrote:
@nikic thanks. Please also revert
https://github.com/llvm/llvm-project/commit/225d8fc8eb24fb797154c1ef6dcbe5ba033142da
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
nikic wrote:
It looks like this PR was merged without being approved, and I also couldn't
find the corresponding RFC for this addition on discourse. I've reverted it for
now.
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing lis
https://github.com/dyung edited https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -798,6 +804,12 @@
# DEBUG-NEXT: .. opcode {{[0-9]+}} is aliased to {{[0-9]+}}
# DEBUG-NEXT: .. type index coverage check SKIPPED: user-defined predicate
detected
# DEBUG-NEXT: .. imm index coverage check SKIPPED: user-defined predicate
detected
+# DEBUG-NEXT: G_VECREDUCE_F
https://github.com/wzssyqa closed
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15883,6 +15883,100 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -1449,6 +1449,16 @@ inline APFloat minimum(const APFloat &A, const APFloat
&B) {
return A.isNegative() ? A : B;
return B < A ? B : A;
}
+LLVM_READONLY
kuhar wrote:
Please add and an empty line before this function and document its semantics.
https:/
@@ -1462,6 +1472,16 @@ inline APFloat maximum(const APFloat &A, const APFloat
&B) {
return A.isNegative() ? B : A;
return A < B ? B : A;
}
+LLVM_READONLY
kuhar wrote:
also here
https://github.com/llvm/llvm-project/pull/93841
___
@@ -16055,6 +16145,90 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
@@ -16055,6 +16145,90 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
@@ -16055,6 +16145,90 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
@@ -15874,6 +15874,96 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15874,6 +15874,96 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -16055,6 +16145,90 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
@@ -32,27 +32,29 @@ class StoreInst;
/// These are the kinds of recurrences that we support.
enum class RecurKind {
- None, ///< Not a recurrence.
- Add, ///< Sum of integers.
- Mul, ///< Product of integers.
- Or, ///< Bitwise or logical OR of integers
@@ -32,27 +32,29 @@ class StoreInst;
/// These are the kinds of recurrences that we support.
enum class RecurKind {
- None, ///< Not a recurrence.
- Add, ///< Sum of integers.
- Mul, ///< Product of integers.
- Or, ///< Bitwise or logical OR of integers
@@ -9130,6 +9142,15 @@ void SelectionDAGBuilder::visitCall(const CallInst &I) {
if (visitBinaryFloatCall(I, ISD::FMAXNUM))
return;
break;
+ case LibFunc_fminimum_num:
+ case LibFunc_fminimum_numf:
+if (visitBinaryFloatCall(I, ISD::FMI
@@ -9130,6 +9142,15 @@ void SelectionDAGBuilder::visitCall(const CallInst &I) {
if (visitBinaryFloatCall(I, ISD::FMAXNUM))
return;
break;
+ case LibFunc_fminimum_num:
+ case LibFunc_fminimum_numf:
+if (visitBinaryFloatCall(I, ISD::FMI
https://github.com/wzssyqa edited
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -631,6 +631,46 @@ TEST(APFloatTest, Maximum) {
EXPECT_TRUE(std::isnan(maximum(nan, f1).convertToDouble()));
}
+TEST(APFloatTest, MinimumNumber) {
+ APFloat f1(1.0);
+ APFloat f2(2.0);
+ APFloat zp(0.0);
+ APFloat zn(-0.0);
+ APFloat nan = APFloat::getNaN(APFloat::IEE
@@ -1723,6 +1723,18 @@ class MachineIRBuilder {
return buildInstr(TargetOpcode::G_FMAXNUM_IEEE, {Dst}, {Src0, Src1},
Flags);
}
+ MachineInstrBuilder
+ buildFMinimumNUM(const DstOp &Dst, const SrcOp &Src0, const SrcOp &Src1,
jcranmer-intel wrote:
How
@@ -9130,6 +9142,15 @@ void SelectionDAGBuilder::visitCall(const CallInst &I) {
if (visitBinaryFloatCall(I, ISD::FMAXNUM))
return;
break;
+ case LibFunc_fminimum_num:
+ case LibFunc_fminimum_numf:
+if (visitBinaryFloatCall(I, ISD::FMI
@@ -631,6 +631,46 @@ TEST(APFloatTest, Maximum) {
EXPECT_TRUE(std::isnan(maximum(nan, f1).convertToDouble()));
}
+TEST(APFloatTest, MinimumNumber) {
+ APFloat f1(1.0);
+ APFloat f2(2.0);
+ APFloat zp(0.0);
+ APFloat zn(-0.0);
+ APFloat nan = APFloat::getNaN(APFloat::IEE
@@ -1275,6 +1283,14 @@ let IntrProperties = [IntrInaccessibleMemOnly,
IntrWillReturn, IntrStrictFP] in
[ LLVMMatchType<0>,
LLVMMatchType<0>,
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
wzssyqa wrote:
> > 3. PowerPC: has some interaction with the behavior of `minnum/maxnum`: need
> > define `fcanonicalize`.
>
> AMDGPU has the same handling. This is to break the signaling nan handling
> from IEEE to the broken old glibc libm behavior. If we fix the definition to
> match IEEE,
@@ -16049,6 +16094,84 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
peterwaller-arm wrote:
> @peterwaller-arm I noticed that in
> `llvm/test/CodeGen/AArch64/combine_andor_with_cmps.ll`, `FMAXNUM_IEEE` is
> claimed that it is not supported. While I noticed that `fmaxnm` follows the
> rules of `maxNUM` of IEEE754-2008. Is there any other limitation of `fmaxnm`?
@@ -5005,8 +5007,11 @@ void computeKnownFPClass(const Value *V, const APInt
&DemandedElts,
// If either operand is not NaN, the result is not NaN.
if (NeverNaN && (IID == Intrinsic::minnum || IID == Intrinsic::maxnum))
Known.knownNot(fcNan);
+ if (Neve
@@ -16049,6 +16094,84 @@ of the two arguments. -0.0 is considered to be less
than +0.0 for this
intrinsic. Note that these are the semantics specified in the draft of
IEEE 754-2019.
+.. _i_minimumnum:
+
+'``llvm.minimumnum.*``' Intrinsic
+^
+
+
https://github.com/arsenm edited https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3636,6 +3648,22 @@ def Fmin : FPMathTemplate, LibBuiltin<"math.h"> {
let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
}
+def FmaximumNum : FPMathTemplate, LibBuiltin<"math.h"> {
arsenm wrote:
I'd prefer to split the clang changes into a separate change
ht
https://github.com/arsenm commented:
> 3. PowerPC: has some interaction with the behavior of `minnum/maxnum`: need
> define `fcanonicalize`.
AMDGPU has the same handling. This is to break the signaling nan handling from
IEEE to the broken old glibc libm behavior. If we fix the definition to ma
wzssyqa wrote:
TODO: implement for architectures that don't have `fmin/fmax` instructions:
This is the example of MIPS pre-R6:
```
mins:
.setnoreorder
.setnomacro
mtc1$0,$f1
add.s $f0,$f12,$f1
add.s $f13,$f13,$f1
c.un.s $fcc0,$f0
wzssyqa wrote:
@peterwaller-arm I noticed that in
`llvm/test/CodeGen/AArch64/combine_andor_with_cmps.ll`, `FMAXNUM_IEEE` is
claimed that it is not supported. While I noticed that `fmaxnm` follows the
rules of `maxNUM` of IEEE754-2008.
Is there any other limitation of `fmaxnm`?
https://github.
efriedma-quic wrote:
Please add a table to LangRef comparing the behavior of the three versions of
min/max intrinsics for various inputs.
https://github.com/llvm/llvm-project/pull/93841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
wzssyqa wrote:
Since we need to reuse some logic of `minnum/maxnum` to implement
`minimumnum/maximumnum`,
let's add them before switch the behavior of `minnum/maxnum`.
Known not working ports, will be fixed in future PRs:
1. X86: the current `minnum/maxnum` cannot process +0 vs -0 as
`minimu
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 6a3982f8b7e37987659706cb3e6427c54c9bc7ce
d5e151568e1ebea81aabdcc42f753393095610e9 --
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: YunQiang Su (wzssyqa)
Changes
Currently, on different platform, the behaivor of llvm.minnum is different if
one operand is sNaN:
When we compare sNaN vs NUM:
ARM/AArch64/PowerPC: follow the IEEE754-2008's minNUM: return qNaN.
RI
llvmbot wrote:
@llvm/pr-subscribers-backend-x86
Author: YunQiang Su (wzssyqa)
Changes
Currently, on different platform, the behaivor of llvm.minnum is different if
one operand is sNaN:
When we compare sNaN vs NUM:
ARM/AArch64/PowerPC: follow the IEEE754-2008's minNUM: return qNaN.
RISC
llvmbot wrote:
@llvm/pr-subscribers-backend-risc-v
Author: YunQiang Su (wzssyqa)
Changes
Currently, on different platform, the behaivor of llvm.minnum is different if
one operand is sNaN:
When we compare sNaN vs NUM:
ARM/AArch64/PowerPC: follow the IEEE754-2008's minNUM: return qNaN.
R
llvmbot wrote:
@llvm/pr-subscribers-llvm-transforms
@llvm/pr-subscribers-llvm-selectiondag
Author: YunQiang Su (wzssyqa)
Changes
Currently, on different platform, the behaivor of llvm.minnum is different if
one operand is sNaN:
When we compare sNaN vs NUM:
ARM/AArch64/PowerPC: follow th
52 matches
Mail list logo
