https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/71437
Because the SmallVectorImpl destructor is not virtual, the destructor of
derived classes will not be called if pointers to the SmallVectorImpl class are
deleted directly. Making the SmallVectorImpl destructor
https://github.com/andykaylor closed
https://github.com/llvm/llvm-project/pull/71437
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/71439
Because the SmallVectorImpl destructor is not virtual, the destructor of
derived classes will not be called if pointers to the SmallVectorImpl class are
deleted directly. Making the SmallVectorImpl destructor
@@ -95,7 +95,7 @@ class SerializeToHsacoPass
std::unique_ptr>
serializeISA(const std::string &isa) override;
- std::unique_ptr> assembleIsa(const std::string &isa);
+ std::unique_ptr> assembleIsa(const std::string &isa);
andykaylor wrote:
I'm not famili
andykaylor wrote:
> We probably (pretty sure) don't want to add a virtual dtor to SmallVector -
> that'd add a vtable pointer, increasing the size in ways that are probably
> unacceptable given the pervasive use of the data structure.
>
> We should make the Impl dtor protected so it can't be p
andykaylor wrote:
I don't think this change is time-critical. I can wait a few days for the
SerializeToHsaco fix, but if it's going to be more than a few days, I'd prefer
to land this change with an interim fix in SerializeToHsaco. @krzysz00 what's
your preference?
https://github.com/llvm/llv
andykaylor wrote:
It seems like there are two possible interpretations of -ffinite-math-only:
1. There will be no NaN or inf values seen anywhere in the program (other than
loads and stores?).
2. No floating-point operation (other than compares?) will have NaN or inf
inputs or results.
The te
andykaylor wrote:
For those who haven't already seen it, there was a related discussion here:
https://discourse.llvm.org/t/should-isnan-be-optimized-out-in-fast-math-mode/5
I think that discussion could be fairly summarized by saying that no consensus
was reached, and many people wished th
https://github.com/andykaylor edited
https://github.com/llvm/llvm-project/pull/76873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6771,6 +6771,9 @@ def warn_pointer_sub_null_ptr : Warning<
def warn_floatingpoint_eq : Warning<
"comparing floating point with == or != is unsafe">,
InGroup>, DefaultIgnore;
+def warn_fast_floatingpoint_eq : Warning<
+ "explicit comparison with %0 in fast floating poin
https://github.com/andykaylor commented:
Expanding the scope a bit, it would also be useful to have warnings for
constant NaN or Inf values passed as arguments or used in binary operations.
https://github.com/llvm/llvm-project/pull/76873
___
cfe-commi
@@ -2245,6 +2246,11 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl,
unsigned BuiltinID,
case Builtin::BI__builtin_islessequal:
case Builtin::BI__builtin_islessgreater:
case Builtin::BI__builtin_isunordered:
+if (BuiltinID == Builtin::BI__builtin_isunordered) {
@@ -13846,6 +13880,37 @@ Sema::CheckReturnValExpr(Expr *RetValExp, QualType
lhsType,
CheckPPCMMAType(RetValExp->getType(), ReturnLoc);
}
+/// Diagnose comparison to NAN or INFINITY in fast math modes.
+/// The comparison to NaN or INFINITY is always false in
+/// fast mod
@@ -2267,6 +2273,16 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl,
unsigned BuiltinID,
case Builtin::BI__builtin_signbit:
case Builtin::BI__builtin_signbitf:
case Builtin::BI__builtin_signbitl:
+FPO = TheCall->getFPFeaturesInEffect(getLangOpts());
---
@@ -13044,9 +13044,12 @@ static QualType checkArithmeticOrEnumeralCompare(Sema
&S, ExprResult &LHS,
if (Type->isAnyComplexType() && BinaryOperator::isRelationalOp(Opc))
return S.InvalidOperands(Loc, LHS, RHS);
- // Check for comparisons of floating point operands using
@@ -13846,6 +13880,37 @@ Sema::CheckReturnValExpr(Expr *RetValExp, QualType
lhsType,
CheckPPCMMAType(RetValExp->getType(), ReturnLoc);
}
+/// Diagnose comparison to NAN or INFINITY in fast math modes.
+/// The comparison to NaN or INFINITY is always false in
+/// fast mod
@@ -2621,6 +2642,29 @@ SDValue
DAGTypeLegalizer::PromoteFloatRes_FP_ROUND(SDNode *N) {
return DAG.getNode(GetPromotionOpcode(VT, NVT), DL, NVT, Round);
}
+// Explicit operation to reduce precision. Reduce the value to half precision
+// and promote it back to the legal typ
https://github.com/andykaylor edited
https://github.com/llvm/llvm-project/pull/74332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor approved this pull request.
This looks good to me. I've added Phoebe Wang as a reviewer because she knows
the SelectionDAG code better than I do and might want to take a look. I'm
assuming you have reviewed the AMDGPU-specific parts of this with someone who
knows
@@ -13846,6 +13880,37 @@ Sema::CheckReturnValExpr(Expr *RetValExp, QualType
lhsType,
CheckPPCMMAType(RetValExp->getType(), ReturnLoc);
}
+/// Diagnose comparison to NAN or INFINITY in fast math modes.
+/// The comparison to NaN or INFINITY is always false in
+/// fast mod
@@ -2807,9 +2791,17 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
FPExceptionBehavior = "";
// If fast-math is set then set the fp-contract mode to fast.
FPContract = "fast";
-// ffast-math enables limited range rules for compl
@@ -51,11 +51,12 @@ class ComplexExprEmitter
CGBuilderTy &Builder;
bool IgnoreReal;
bool IgnoreImag;
-public:
- ComplexExprEmitter(CodeGenFunction &cgf, bool ir=false, bool ii=false)
-: CGF(cgf), Builder(CGF.Builder), IgnoreReal(ir), IgnoreImag(ii) {
- }
+ LangOpti
@@ -794,8 +834,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo &Op) {
ResR = Builder.CreateFSub(AC, BD, "mul_r");
ResI = Builder.CreateFAdd(AD, BC, "mul_i");
- if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited ||
- Op.
@@ -2807,9 +2791,17 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
FPExceptionBehavior = "";
// If fast-math is set then set the fp-contract mode to fast.
FPContract = "fast";
-// ffast-math enables limited range rules for compl
@@ -986,13 +1028,17 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo &Op) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+Qua
@@ -2824,26 +2816,89 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
switch (optID) {
default:
break;
-case options::OPT_fcx_limited_range: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Limited);
-
@@ -986,13 +1028,17 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo &Op) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+Qua
@@ -794,8 +834,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo &Op) {
ResR = Builder.CreateFSub(AC, BD, "mul_r");
ResI = Builder.CreateFAdd(AD, BC, "mul_i");
- if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited ||
- Op.
@@ -2824,26 +2816,89 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
switch (optID) {
default:
break;
-case options::OPT_fcx_limited_range: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Limited);
-
https://github.com/andykaylor commented:
Except for lacking a couple of tests, I think this looks good. @jcranmer-intel
do you agree?
https://github.com/llvm/llvm-project/pull/81514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/andykaylor edited
https://github.com/llvm/llvm-project/pull/81514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
andykaylor wrote:
Can you add test cases for targets that will have problems with promotion.
Something like this?
```
// RUN: %clang_cc1 -triple x86_64-windows-pc \
// RUN: -complex-range=promoted -emit-llvm -o - %s \
// RUN: | FileCheck %s --check-prefix=X86W
https://github.com/andykaylor approved this pull request.
This looks good to me. Thanks for the updates!
https://github.com/llvm/llvm-project/pull/81514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
andykaylor wrote:
> > I may have mentioned a few times that I don't like function attributes
> > controlling fast-math behaviors.
>
> It doesn't control it, it's informative. You just get undefined behavior if
> you end up calling mismatched mode functions.
What I meant to say was that I don'
andykaylor wrote:
> > > So, alternatively...we could just go with the simplest solution, and use
> > > "ieee" as the default even under -ffast-math.
>
> +1. **There hasn't been a performance reason to use FTZ/DAZ since ~2011.**
> Maybe there's still a power benefit? But in that case you could
andykaylor wrote:
> Just to be clear: I'm not proposing entirely eliminating the "link against
> crtfastmath.o" behavior, when linking a binary with `-ffast-math` (though,
> separately from _this_ review, that may be worth considering!). I only meant
> we should stop attempting to infer anythi
andykaylor wrote:
> I'm suggesting that we modify Clang so that `-ffast-math` _doesn't affect_
> `denormal-fp-math`, by (as I mentioned before) removing the overload
> [Linux::getDefaultDenormalModeForType](https://github.com/llvm/llvm-project/blob/d4c5acac99e83ffa12d2d720c9e502a181cbd7ea/clang
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/81173
This refactors the fast-math handling in the clang driver, moving the settings
into a lambda that is shared by the -ffp-model=fast and -ffast-math code.
Previously the -ffp-model=fast handler changed the loca
@@ -3061,22 +3080,7 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
continue;
[[fallthrough]];
andykaylor wrote:
This is falling through from OPT_Ofast to OPT_ffast_math. I think we still want
that to happen. It's
@@ -2842,9 +2862,8 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
<< Args.MakeArgString("-ffp-model=" + FPModel)
<< Args.MakeArgString("-ffp-model=" + Val);
if (Val.equals("fast")) {
-optID = options::OPT_f
@@ -2842,9 +2862,8 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
<< Args.MakeArgString("-ffp-model=" + FPModel)
<< Args.MakeArgString("-ffp-model=" + Val);
if (Val.equals("fast")) {
-optID = options::OPT_f
https://github.com/andykaylor edited
https://github.com/llvm/llvm-project/pull/81173
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
andykaylor wrote:
> > I'd like to see this change land, but with the "-mdaz-ftz" option removed
> > (because I don't think it's useful). That would fix the critical problem of
> > fast-math infecting shared libraries with the ftz setting, and we could
> > straighten out the other problems, whi
andykaylor wrote:
> > I don't see why the current denormal-fp-math setting behavior is a blocking
> > issue for this change
>
> Because this PR as-is causes us to start parsing the "-shared" flag for
> compilation actions in order to determine which denormal-fp-math setting to
> use. Users sh
andykaylor wrote:
I just created https://github.com/llvm/llvm-project/issues/81204 to describe
the linking versus compiling problem.
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/andykaylor approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/81108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
andykaylor wrote:
> I don't think it's unreasonable to switch the logic of `-mdaz-ftz` from
> linking a file with a global initializer that sets the flags to making it
> emit the entry-point call to such a function instead, it still largely
> follows the same logic to me. And having a command
@@ -1569,6 +1569,40 @@
// RUN:--gcc-toolchain="" \
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
+// Don't link crtfastmath.o with -shared
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -###
@@ -117,6 +117,11 @@ C23 Feature Support
Non-comprehensive list of changes in this release
-
+* Code compiled with ``-shared`` and ``-ffast-math`` will no longer enable
+ flush-to-zero floating-point mode by default. This decisi
@@ -117,6 +117,11 @@ C23 Feature Support
Non-comprehensive list of changes in this release
-
+* Code compiled with ``-shared`` and ``-ffast-math`` will no longer enable
andykaylor wrote:
```suggestion
* Code com
https://github.com/andykaylor closed
https://github.com/llvm/llvm-project/pull/81173
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -283,9 +283,23 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType getPromotionType(QualType Ty, bool IsDivOpCode = f
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType E
@@ -1847,19 +1847,50 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
+.. option:: -fcomplex-arithmetic=:
+
+ This option specifies the impl
andykaylor wrote:
I don't know anything about how non-x86 targets implement DAZ/FTZ, but for
x86-based targets, I think trying to make any assumptions about the setting is
bound to be wrong. In theory, it's part of the floating-point environment and
shouldn't be modified during execution unles
andykaylor wrote:
> > (Sidenote: "dynamic" isn't even
> > [documented](https://clang.llvm.org/docs/UsersManual.html#cmdoption-fdenormal-fp-math)).
>
> It's not a selectable enum of the Clang `-fdenormal-fp-math` flag, but it is
> one for the LLVM function attribute `denormal-fp-math`.
This is
@@ -6771,6 +6771,11 @@ def warn_pointer_sub_null_ptr : Warning<
def warn_floatingpoint_eq : Warning<
"comparing floating point with == or != is unsafe">,
InGroup>, DefaultIgnore;
+def warn_fast_floatingpoint_eq : Warning<
+ "use of %select{infinity|NaN}0 will always be 'fa
@@ -2780,24 +2781,24 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
case options::OPT_fcx_limited_range: {
EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Limited);
Range = LangOptions::ComplexRangeKind::CX_Lim
andykaylor wrote:
@MaskRay I see that in 3bbc912d37f03d9ad3be330b81d91c2eaf6c37f2 you removed
some tests that fail because of this change. Why do you think that is an
appropriate solution? I have some other tests in a downstream product that are
failing because we build with CLANG_DEFAULT_PIE_
andykaylor wrote:
> I mean that we could lazily emit a helper function like
> `__clang_smiths_division_double` and call it instead of emitting like twenty
> instructions inline.
That's a reasonable suggestion. We may also want to add the ability to emit a
helper function to handle the full ra
andykaylor wrote:
> > @MaskRay I see that in
> > [3bbc912](https://github.com/llvm/llvm-project/commit/3bbc912d37f03d9ad3be330b81d91c2eaf6c37f2)
> > you removed some tests that fail because of this change. Why do you think
> > that is an appropriate solution? I have some other tests in a downs
@@ -2835,6 +2835,9 @@ class Preprocessor {
if (Identifier.getIdentifierInfo()->isRestrictExpansion() &&
!SourceMgr.isInMainFile(Identifier.getLocation()))
emitRestrictExpansionWarning(Identifier);
+
+if (Identifier.getIdentifierInfo()->getName() == "INFINI
https://github.com/andykaylor approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/78330
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor approved this pull request.
I'm happy with this.
https://github.com/llvm/llvm-project/pull/76873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/69797
None
>From 856a471b40f19f5fcf6aab7591009555b6a3841f Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 20 Oct 2023 12:33:51 -0700
Subject: [PATCH 1/2] Update SimplifyIndVar.cpp
In SimplifyIndvar::replaceF
https://github.com/andykaylor closed
https://github.com/llvm/llvm-project/pull/69797
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor edited
https://github.com/llvm/llvm-project/pull/68267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor commented:
Thanks for adding this! I have just a few minor comments.
https://github.com/llvm/llvm-project/pull/68267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
@@ -4609,6 +4609,22 @@ The pragma can take two values: ``on`` and ``off``.
float v = t + z;
}
+``#pragma clang fp reciprocal`` allows control over using reciprocal
+approximations in floating point expressions. When enabled, this
+pragma allows the expression ``x / y`` t
@@ -1309,6 +1309,13 @@ void Sema::ActOnPragmaFPReassociate(SourceLocation Loc,
bool IsEnabled) {
CurFPFeatures = NewFPFeatures.applyOverrides(getLangOpts());
}
+void Sema::ActOnPragmaFPReciprocal(SourceLocation Loc, bool IsEnabled) {
andykaylor wrote:
This
andykaylor wrote:
err_pragma_fp_invalid_option needs to be updated to add 'reciprocal'
https://github.com/llvm/llvm-project/pull/68267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
@@ -1309,6 +1309,13 @@ void Sema::ActOnPragmaFPReassociate(SourceLocation Loc,
bool IsEnabled) {
CurFPFeatures = NewFPFeatures.applyOverrides(getLangOpts());
}
+void Sema::ActOnPragmaFPReciprocal(SourceLocation Loc, bool IsEnabled) {
andykaylor wrote:
Ther
@@ -2339,6 +2345,28 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
// LLVM counterparts if the call is marked 'const' (known to never set
errno).
// In case FP exceptions are enabled, the experimental versions of the
// intrinsics mo
@@ -396,7 +396,41 @@ class LangOptionsBase {
IncompleteOnly = 3,
};
- enum ComplexRangeKind { CX_Full, CX_Limited, CX_Fortran, CX_None };
+ /// Controls the various implementations for complex multiplication and
+ // division.
+ enum ComplexRangeKind {
+/// Imple
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -79,29 +91,152 @@ _Complex float pragma_on_div(_Complex float a, _Complex
float b) {
// LMTD-NEXT: fdiv float
// LMTD-NEXT: fdiv float
- // FRTRN: fmul float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fadd float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fmul
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1041,28 +1041,15 @@ defm offload_uniform_block :
BoolFOption<"offload-uniform-block",
NegFlag,
BothFlags<[], [ClangOption], " that kernels are launched with uniform block
sizes (default true for CUDA/HIP and false otherwise)">>;
-def fcx_limited_range : Joined<["-"],
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType E
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType E
@@ -67,41 +79,164 @@ _Complex float pragma_on_div(_Complex float a, _Complex
float b) {
// FULL-NEXT: fdiv float
// FULL: fdiv float
- // LMTD: fmul float
- // LMTD-NEXT: fmul float
- // LMTD-NEXT: fadd float
- // LMTD-NEXT: fmul float
- // LMTD-NEXT: fmul float
- /
@@ -1041,28 +1041,15 @@ defm offload_uniform_block :
BoolFOption<"offload-uniform-block",
NegFlag,
BothFlags<[], [ClangOption], " that kernels are launched with uniform block
sizes (default true for CUDA/HIP and false otherwise)">>;
-def fcx_limited_range : Joined<["-"],
@@ -1041,28 +1041,15 @@ defm offload_uniform_block :
BoolFOption<"offload-uniform-block",
NegFlag,
BothFlags<[], [ClangOption], " that kernels are launched with uniform block
sizes (default true for CUDA/HIP and false otherwise)">>;
-def fcx_limited_range : Joined<["-"],
@@ -816,6 +816,11 @@ class FPOptions {
setAllowFPReassociate(LO.AllowFPReassoc);
setNoHonorNaNs(LO.NoHonorNaNs);
setNoHonorInfs(LO.NoHonorInfs);
+// Ensure that if FiniteMathOnly is enabled, NoHonorNaNs and NoHonorInfs
are
+// also enabled. This is because
andykaylor wrote:
@kpneal I think the tolerance of excess precision is mostly a concession to the
hardware limitations. I believe we only apply it when half-precision types are
used but the hardware doesn't support native half-precision operations. In this
sense, it is equivalent to the situat
andykaylor wrote:
@MaskRay Are you OK with this change?
https://github.com/llvm/llvm-project/pull/100453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/89473
This changes the handling of -fno-unsafe-fp-math to stop having that
option imply -ftrapping-math. In gcc, -fno-unsafe-math-optimizations sets
-ftrapping-math, but that dependency is based on the fact the
-ftra
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/89477
This is an attempt to better align the denormal handling of
-ffp-model=fast with the behavior of -ffast-math. The clang user's
manual claims that -ffp-model=fast "behaves identically to specifying
both -ffast-m
1 - 100 of 624 matches
Mail list logo
