[clang] [NFC] Add assertion to ensure FiniteMathOnly is in sync with HonorINFs and HonorNANs. (PR #97342)
@@ -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 FiniteMathOnly mode assumes no NaNs or
Infs
+// are present in computations.
+if (!LO.NoHonorInfs || !LO.NoHonorInfs)
+ assert(!LO.FiniteMathOnly && "FiniteMathOnly implies NoHonorInfs");
andykaylor wrote:
I agree with Aaron that we should get rid of the internal state that combines
these two modes. I expect we'll only want to define `__FINITE_MATH_ONLY__` when
we aren't honoring either. You could create code that made incorrect
assumptions either way, but the state described by the symbol is that we aren't
honoring either.
https://github.com/llvm/llvm-project/pull/97342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Clean up fp-contract handling in clang driver (PR #91271)
@@ -238,3 +238,17 @@ // RUN: %clang -### -fno-unsafe-math-optimizations -funsafe-math-optimizations \ // RUN: -ffp-contract=off -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s +// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off -c %s 2>&1 \ andykaylor wrote: That introduces a merge conflict for this patch. Is there a way I can solve that without having to do a rebase and force push for this, which kills the ability to see what changed between updates? I guess with a small-ish patch like this that's not a big problem, but it's something I try to avoid in general. https://github.com/llvm/llvm-project/pull/91271 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Clean up fp-contract handling in clang driver (PR #91271)
@@ -2893,7 +2915,6 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , AssociativeMath = false; ReciprocalMath = false; SignedZeros = true; - FPContract = "on"; andykaylor wrote: It was unnecessary. Only one of the three fp-models sets FPContract to "on" and that's happening explicitly below. The code here is setting everything to what it would be for fp-model=precise and then resetting it immediately if we're handling -ffp-model=fast. Except for the FPContract state, these are right for fp-model strict as well. https://github.com/llvm/llvm-project/pull/91271 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Clean up fp-contract handling in clang driver (PR #91271)
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/91271
This change refactors the fp-contract handling in
RenderFloatingPointOptions in the clang driver code and fixes some
inconsistencies in the way warnings are reported for changes in the
fp-contract behavior.
>From 596ec4fa32dffb9b710ec90d3cafa76fb3bf4b69 Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Mon, 6 May 2024 10:07:52 -0700
Subject: [PATCH] [Driver] Clean up fp-contract handling in clang driver
This change refactors the fp-contract handling in
RenderFloatingPointOptions in the clang driver code and fixes some
inconsistencies in the way warnings are reported for changes in the
fp-contract behavior.
---
clang/lib/Driver/ToolChains/Clang.cpp | 90 ---
clang/test/Driver/fp-contract.c | 14 +
clang/test/Driver/fp-model.c | 14 +
3 files changed, 81 insertions(+), 37 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 0a2ea96de73824..b1400770f59d53 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2751,6 +2751,7 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
// If one wasn't given by the user, don't pass it here.
StringRef FPContract;
StringRef LastSeenFfpContractOption;
+ StringRef LastFpContractOverrideOption;
bool SeenUnsafeMathModeOption = false;
if (!JA.isDeviceOffloading(Action::OFK_Cuda) &&
!JA.isOffloading(Action::OFK_HIP))
@@ -2792,6 +2793,27 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
SeenUnsafeMathModeOption = true;
};
+ // Lambda to consolidate common handling for fp-contract
+ auto restoreFPContractState = [&]() {
+// CUDA and HIP don't rely on the frontend to pass an ffp-contract option.
+// For other targets, if the state has been changed by one of the
+// unsafe-math umbrella options a subsequent -fno-fast-math or
+// -fno-unsafe-math-optimizations option reverts to the last value seen for
+// the -ffp-contract option or "on" if we have not seen the -ffp-contract
+// option. If we have not seen an unsafe-math option or -ffp-contract,
+// we leave the FPContract state unchanged.
+if (!JA.isDeviceOffloading(Action::OFK_Cuda) &&
+!JA.isOffloading(Action::OFK_HIP)) {
+ if (LastSeenFfpContractOption != "")
+FPContract = LastSeenFfpContractOption;
+ else if (SeenUnsafeMathModeOption)
+FPContract = "on";
+}
+// In this case, we're reverting to the last explicit fp-contract option
+// or the platform default
+LastFpContractOverrideOption = "";
+ };
+
if (const Arg *A = Args.getLastArg(options::OPT_flimited_precision_EQ)) {
CmdArgs.push_back("-mlimit-float-precision");
CmdArgs.push_back(A->getValue());
@@ -2893,7 +2915,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
AssociativeMath = false;
ReciprocalMath = false;
SignedZeros = true;
- FPContract = "on";
StringRef Val = A->getValue();
if (OFastEnabled && !Val.equals("fast")) {
@@ -2910,14 +2931,18 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// applyFastMath sets fp-contract="fast"
+LastFpContractOverrideOption = "-ffp-model=fast";
} else if (Val.equals("precise")) {
FPModel = Val;
FPContract = "on";
+LastFpContractOverrideOption = "-ffp-model=precise";
} else if (Val.equals("strict")) {
StrictFPModel = true;
FPExceptionBehavior = "strict";
FPModel = Val;
FPContract = "off";
+LastFpContractOverrideOption = "-ffp-model=strict";
TrappingMath = true;
RoundingFPMath = true;
} else
@@ -2996,8 +3021,15 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
StringRef Val = A->getValue();
if (Val.equals("fast") || Val.equals("on") || Val.equals("off") ||
Val.equals("fast-honor-pragmas")) {
+if (Val != FPContract && LastFpContractOverrideOption != "") {
+ D.Diag(clang::diag::warn_drv_overriding_option)
+ << LastFpContractOverrideOption
+ << Args.MakeArgString("-ffp-contract=" + Val);
+}
+
FPContract = Val;
LastSeenFfpContractOption = Val;
+LastFpContractOverrideOption = "";
} else
D.Diag(diag::err_drv_unsupported_option_argument)
<< A->getSpelling() << Val;
@@ -3077,6 +3109,7 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
TrappingMath = false;
FPExceptionBehavior = "";
FPContract = "fast";
+ LastFpContractOverrideOption = "-funsafe-math-optimizations";
SeenUnsafeMathModeOption = true;
break;
[clang] [NFC][Driver] Clean up RenderFloatingPointOptions() (PR #91017)
https://github.com/andykaylor closed https://github.com/llvm/llvm-project/pull/91017 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][Driver] Clean up RenderFloatingPointOptions() (PR #91017)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/91017
>From 82e51e4cea0cb889842273fcac874bb52d6bd780 Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 3 May 2024 14:14:58 -0700
Subject: [PATCH 1/2] [NFC][Driver] Clean up RenderFloatingPointOptions()
This change refactors RenderFloatingPointOptions() to eliminate some
excessively complicated logic and a redundant switch statement. The
logic being simplified is an artifact of the original -ffp-model
implementation, and over time it has become unnecessary.
The handling of diagnostics related to the -ffp-contract option is
still a bit convoluted after this change. I will address that in a
subsequent patch because I think it will make sense to make some minor
changes to the driver behavior when that is cleaned up. The current
patch should not make any change to observable behavior of the driver.
---
clang/lib/Driver/ToolChains/Clang.cpp | 56 ---
1 file changed, 17 insertions(+), 39 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index f9ca76a5ac8007..92860766298c26 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2736,7 +2736,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
bool TrappingMathPresent = false; // Is trapping-math in args, and not
// overriden by ffp-exception-behavior?
bool RoundingFPMath = false;
- bool RoundingMathPresent = false; // Is rounding-math in args?
// -ffp-model values: strict, fast, precise
StringRef FPModel = "";
// -ffp-exception-behavior options: strict, maytrap, ignore
@@ -2799,11 +2798,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
for (const Arg *A : Args) {
-auto optID = A->getOption().getID();
-bool PreciseFPModel = false;
-switch (optID) {
-default:
- break;
+switch (A->getOption().getID()) {
+// If this isn't an FP option skip the claim below
+default: continue;
+
case options::OPT_fcx_limited_range:
if (GccRangeComplexOption.empty()) {
if (Range != LangOptions::ComplexRangeKind::CX_Basic)
@@ -2885,6 +2883,7 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
Range = RangeVal;
break;
}
+
case options::OPT_ffp_model_EQ: {
// If -ffp-model= is seen, reset to fno-fast-math
HonorINFs = true;
@@ -2895,7 +2894,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
AssociativeMath = false;
ReciprocalMath = false;
SignedZeros = true;
- // -fno_fast_math restores default denormal and fpcontract handling
FPContract = "on";
StringRef Val = A->getValue();
@@ -2906,10 +2904,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
break;
}
StrictFPModel = false;
- PreciseFPModel = true;
- // ffp-model= is a Driver option, it is entirely rewritten into more
- // granular options before being passed into cc1.
- // Use the gcc option in the switch below.
if (!FPModel.empty() && !FPModel.equals(Val))
D.Diag(clang::diag::warn_drv_overriding_option)
<< Args.MakeArgString("-ffp-model=" + FPModel)
@@ -2918,27 +2912,20 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
FPModel = Val;
applyFastMath();
} else if (Val.equals("precise")) {
-optID = options::OPT_ffp_contract;
FPModel = Val;
FPContract = "on";
-PreciseFPModel = true;
} else if (Val.equals("strict")) {
StrictFPModel = true;
-optID = options::OPT_frounding_math;
FPExceptionBehavior = "strict";
FPModel = Val;
FPContract = "off";
TrappingMath = true;
+RoundingFPMath = true;
} else
D.Diag(diag::err_drv_unsupported_option_argument)
<< A->getSpelling() << Val;
break;
}
-}
-
-switch (optID) {
-// If this isn't an FP option skip the claim below
-default: continue;
// Options controlling individual features
case options::OPT_fhonor_infinities:HonorINFs = true; break;
@@ -2982,12 +2969,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
case options::OPT_frounding_math:
RoundingFPMath = true;
- RoundingMathPresent = true;
break;
case options::OPT_fno_rounding_math:
RoundingFPMath = false;
- RoundingMathPresent = false;
break;
case options::OPT_fdenormal_fp_math_EQ:
@@ -3010,13 +2995,8 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
// Validate and pass through -ffp-contract option.
case options::OPT_ffp_contract: {
StringRef Val = A->getValue();
- if (PreciseFPModel) {
-
[clang] [NFC][Driver] Clean up RenderFloatingPointOptions() (PR #91017)
@@ -3225,11 +3204,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (!FPContract.empty())
CmdArgs.push_back(Args.MakeArgString("-ffp-contract=" + FPContract));
- if (!RoundingFPMath)
-CmdArgs.push_back(Args.MakeArgString("-fno-rounding-math"));
-
- if (RoundingFPMath && RoundingMathPresent)
andykaylor wrote:
Every place in the code that sets RoundingFPMath to true also sets
RoundingMathPresent to true, so this variable was entirely redundant.
https://github.com/llvm/llvm-project/pull/91017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][Driver] Clean up RenderFloatingPointOptions() (PR #91017)
@@ -3010,13 +2995,8 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
// Validate and pass through -ffp-contract option.
case options::OPT_ffp_contract: {
StringRef Val = A->getValue();
- if (PreciseFPModel) {
andykaylor wrote:
Near as I can tell, the only thing PreciseFPModel was still being used for was
to allow us to detect that we had gotten here as a result of the
OPT_ffp_model_EQ handler above changing the value of optID and falling through
to the second `switch (optID)` statement, and the only effect it had was to
keep us from setting LastSeenFfpContractOption. Since I am eliminating the
fallthrough and the redundant switch statement, this value is no longer needed.
https://github.com/llvm/llvm-project/pull/91017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][Driver] Clean up RenderFloatingPointOptions() (PR #91017)
https://github.com/andykaylor created
https://github.com/llvm/llvm-project/pull/91017
This change refactors RenderFloatingPointOptions() to eliminate some
excessively complicated logic and a redundant switch statement. The
logic being simplified is an artifact of the original -ffp-model
implementation, and over time it has become unnecessary.
The handling of diagnostics related to the -ffp-contract option is
still a bit convoluted after this change. I will address that in a
subsequent patch because I think it will make sense to make some minor
changes to the driver behavior when that is cleaned up. The current
patch should not make any change to observable behavior of the driver.
>From 82e51e4cea0cb889842273fcac874bb52d6bd780 Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 3 May 2024 14:14:58 -0700
Subject: [PATCH] [NFC][Driver] Clean up RenderFloatingPointOptions()
This change refactors RenderFloatingPointOptions() to eliminate some
excessively complicated logic and a redundant switch statement. The
logic being simplified is an artifact of the original -ffp-model
implementation, and over time it has become unnecessary.
The handling of diagnostics related to the -ffp-contract option is
still a bit convoluted after this change. I will address that in a
subsequent patch because I think it will make sense to make some minor
changes to the driver behavior when that is cleaned up. The current
patch should not make any change to observable behavior of the driver.
---
clang/lib/Driver/ToolChains/Clang.cpp | 56 ---
1 file changed, 17 insertions(+), 39 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index f9ca76a5ac8007..92860766298c26 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2736,7 +2736,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
bool TrappingMathPresent = false; // Is trapping-math in args, and not
// overriden by ffp-exception-behavior?
bool RoundingFPMath = false;
- bool RoundingMathPresent = false; // Is rounding-math in args?
// -ffp-model values: strict, fast, precise
StringRef FPModel = "";
// -ffp-exception-behavior options: strict, maytrap, ignore
@@ -2799,11 +2798,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
for (const Arg *A : Args) {
-auto optID = A->getOption().getID();
-bool PreciseFPModel = false;
-switch (optID) {
-default:
- break;
+switch (A->getOption().getID()) {
+// If this isn't an FP option skip the claim below
+default: continue;
+
case options::OPT_fcx_limited_range:
if (GccRangeComplexOption.empty()) {
if (Range != LangOptions::ComplexRangeKind::CX_Basic)
@@ -2885,6 +2883,7 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
Range = RangeVal;
break;
}
+
case options::OPT_ffp_model_EQ: {
// If -ffp-model= is seen, reset to fno-fast-math
HonorINFs = true;
@@ -2895,7 +2894,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
AssociativeMath = false;
ReciprocalMath = false;
SignedZeros = true;
- // -fno_fast_math restores default denormal and fpcontract handling
FPContract = "on";
StringRef Val = A->getValue();
@@ -2906,10 +2904,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
break;
}
StrictFPModel = false;
- PreciseFPModel = true;
- // ffp-model= is a Driver option, it is entirely rewritten into more
- // granular options before being passed into cc1.
- // Use the gcc option in the switch below.
if (!FPModel.empty() && !FPModel.equals(Val))
D.Diag(clang::diag::warn_drv_overriding_option)
<< Args.MakeArgString("-ffp-model=" + FPModel)
@@ -2918,27 +2912,20 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
FPModel = Val;
applyFastMath();
} else if (Val.equals("precise")) {
-optID = options::OPT_ffp_contract;
FPModel = Val;
FPContract = "on";
-PreciseFPModel = true;
} else if (Val.equals("strict")) {
StrictFPModel = true;
-optID = options::OPT_frounding_math;
FPExceptionBehavior = "strict";
FPModel = Val;
FPContract = "off";
TrappingMath = true;
+RoundingFPMath = true;
} else
D.Diag(diag::err_drv_unsupported_option_argument)
<< A->getSpelling() << Val;
break;
}
-}
-
-switch (optID) {
-// If this isn't an FP option skip the claim below
-default: continue;
// Options controlling individual features
case options::OPT_fhonor_infinities:HonorINFs = true; break;
@@ -2982,12 +2969,10 @@ static void
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
https://github.com/andykaylor closed https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
andykaylor wrote: ping for review https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Clean up denormal handling with fast-math-related options (PR #89477)
https://github.com/andykaylor closed https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Clean up denormal handling with fast-math-related options (PR #89477)
https://github.com/andykaylor edited https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/8] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] [clang][CodeGen] Propagate pragma set fast-math flags to floating point builtins (PR #90377)
https://github.com/andykaylor approved this pull request. This looks right to me, but @zahiraam is more familiar with this code than I am. Zahira, do you have any comments? https://github.com/llvm/llvm-project/pull/90377 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
@@ -64,7 +64,8 @@ // RUN: %clang -### -ffp-model=strict -fdenormal-fp-math=preserve-sign,preserve-sign -c %s 2>&1 \ andykaylor wrote: I didn't intend to change the logic of this test. The behavior here should be target-independent now. https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
andykaylor wrote: > LGTM. May be no need for the "etc" in the title of the patch? Thanks. The "etc." is eliding -fno-fast-math, -funsafe-math-optimizations, and -fno-unsafe-math-optimizations https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/7] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/6] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
@@ -75,6 +76,7 @@ // RUN: --check-prefix=WARN12 %s // RUN: %clang -### -ffast-math -ffp-model=strict -c %s 2>&1 | FileCheck \ // RUN: --check-prefix=WARN12 %s +// WARN12: clang andykaylor wrote: The only purpose of the check here is to establish a reference point for the WARN12-NOT check on the following line. I can change the thing I'm checking to "-cc1" if that will cause less confusion for people reading the test. https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/5] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
@@ -1314,11 +1314,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
return false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
andykaylor wrote:
I hope to add -ffp-model=aggressive soon, with will require a second use of
Model here.
https://github.com/llvm/llvm-project/pull/89477
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/4] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
andykaylor wrote: I've updated this change to account for the changes made in https://github.com/llvm/llvm-project/pull/80475 and made corresponding updated to the PR title and description. https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)
https://github.com/andykaylor edited https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)
https://github.com/andykaylor edited https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)
https://github.com/andykaylor updated
https://github.com/llvm/llvm-project/pull/89477
>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/3] Clean up denormal handling with -ffp-model, -ffast-math,
etc.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst| 4 ++--
clang/lib/Driver/ToolChain.cpp| 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp | 4
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c| 3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (Model != "fast")
+Default = false;
+}
}
// Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s
-funsafe-math-optimizations\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
andykaylor wrote: > One final nit before you submit, though: please update the PR description and > the release notes to also mention that x86 no longer modifies > `-fdenormal-fp-math` based on `-ffast-math`. The Clang User's Manual makes some contradictory statements about this. In one place it says, `-fno-fast-math` resets `-fdenormal-fp-math=` to its target-dependent default, but just a few lines later it says "-fno-fast-math implies -fdenormal-fp-math=ieee" which isn't true for all targets. It says `-fno-unsafe-math-optimizations` implies '-fdenormal-fp-math=ieee` which, unfortunately, is currently be true. The User's Manual also says that `-ffp-model=fast` sets `denormal_fp_math` to IEEE, which is currently true, but really shouldn't be. I'm working on a PR to fix the fp-model handling, which I'll update after this PR lands. I can fix the other issues I've mentioned here in that patch. There are a few points that I am not quite clear on. I'm going to start a Discourse topic to summarize what we've agreed on here and discuss the things I'm not sure about. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)
andykaylor wrote: This patch will need extensive changes once https://github.com/llvm/llvm-project/pull/80475 lands. We're basically decoupling "denormal-fp-math" from fast-math, but I think we still want to link "crtfastmath.o" when --fp-model=fast is used, as we do with -ffast-math. https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
@@ -842,25 +842,6 @@ void Linux::addProfileRTLibs(const llvm::opt::ArgList
,
ToolChain::addProfileRTLibs(Args, CmdArgs);
}
-llvm::DenormalMode
-Linux::getDefaultDenormalModeForType(const llvm::opt::ArgList ,
- const JobAction ,
- const llvm::fltSemantics *FPType) const {
- switch (getTriple().getArch()) {
andykaylor wrote:
I didn't think that had been resolved, but I agree that this change is good
as-is.
It's not just fast-math that can change ftz/daz though. Users can also modify
MXCSR directly. In C, FENV_ACCESS needs to be enabled, but in practice I find
that users would like to be able to do that without taking on the other
penalties associated with enabling fenv access (such as generally diminished
optimization). It would be nice if LLVM IR had a way to allow this.
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
https://github.com/andykaylor updated https://github.com/llvm/llvm-project/pull/89473 >From a137c023aaf5ccc174d347b7bda403bf15d683ae Mon Sep 17 00:00:00 2001 From: Andy Kaylor Date: Wed, 24 Apr 2024 12:35:49 -0700 Subject: [PATCH] Fix -fno-unsafe-math-optimizations behavior 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 -ftrapping-math is enabled by default in gcc. Because clang does not enabled -ftrapping-math by default, there is no reason for -fno-unsafe-math-optimizations to set it. On the other hand, -funsafe-math-optimizations continues to imply -fno-trapping-math because this option necessarily disables strict exception semantics. This fixes https://github.com/llvm/llvm-project/issues/87523 --- clang/docs/UsersManual.rst| 1 - clang/lib/Driver/ToolChains/Clang.cpp | 2 -- clang/test/Driver/fast-math.c | 7 +++ 3 files changed, 3 insertions(+), 7 deletions(-) diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst index 8df40566fcba3d..fb0ade943999a5 100644 --- a/clang/docs/UsersManual.rst +++ b/clang/docs/UsersManual.rst @@ -1690,7 +1690,6 @@ floating point semantic models: precise (the default), strict, and fast. * ``-fno-associative-math`` * ``-fno-reciprocal-math`` * ``-fsigned-zeros`` - * ``-ftrapping-math`` * ``-ffp-contract=on`` * ``-fdenormal-fp-math=ieee`` diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp index 5f5d720cf759f4..a4755248180294 100644 --- a/clang/lib/Driver/ToolChains/Clang.cpp +++ b/clang/lib/Driver/ToolChains/Clang.cpp @@ -3151,8 +3151,6 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , ReciprocalMath = false; SignedZeros = true; ApproxFunc = false; - TrappingMath = true; - FPExceptionBehavior = "strict"; // The target may have opted to flush by default, so force IEEE. DenormalFPMath = llvm::DenormalMode::getIEEE(); diff --git a/clang/test/Driver/fast-math.c b/clang/test/Driver/fast-math.c index b07d5732932cdb..274f1f22ea5e9e 100644 --- a/clang/test/Driver/fast-math.c +++ b/clang/test/Driver/fast-math.c @@ -157,7 +157,7 @@ // FIXME: This case leaves nnan and ninf. That seems wrong! // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ -// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NINF,NNAN,FINITE-ONLY,NO-REASSOC,NO-NSZ,NO-ARCP,NO-AFN,NOROUNDING %s +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NINF,NNAN,FINITE-ONLY,NO-REASSOC,NO-NSZ,NO-ARCP,NO-AFN,NOROUNDING,NO-TRAPPING %s // RUN: %clang -### -ffast-math -fmath-errno -c %s 2>&1 \ // RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NINF,NNAN,FINITE-ONLY,REASSOC,NSZ,ARCP,AFN,CONTRACT-FAST,ERRNO,NOROUNDING %s // RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \ @@ -209,7 +209,7 @@ // RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \ // RUN: -c %s 2>&1 \ -// RUN: | FileCheck --check-prefixes=CHECK,NO-UNSAFE,NO-REASSOC,NO-ARCP,NO-NSZ,NO-AFN %s +// RUN: | FileCheck --check-prefixes=CHECK,NO-UNSAFE,NO-REASSOC,NO-ARCP,NO-NSZ,NO-AFN,NO-TRAPPING %s // RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \ // RUN: | FileCheck --check-prefixes=CHECK,NO-UNSAFE,NO-REASSOC,ARCP,NSZ,AFN %s @@ -224,9 +224,8 @@ // RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \ // RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NO-UNSAFE,ARCP,NSZ,AFN,TRAPPING %s -// FIXME: -fno-unsafe-math-optimizations shouldn't imply trapping math // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ -// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NO-UNSAFE,NO-ARCP,NO-NSZ,NO-AFN,TRAPPING %s +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NO-UNSAFE,NO-ARCP,NO-NSZ,NO-AFN,NO-TRAPPING %s // Reassociate is allowed because it does not require reciprocal-math. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
https://github.com/andykaylor approved this pull request. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
@@ -842,25 +842,6 @@ void Linux::addProfileRTLibs(const llvm::opt::ArgList
,
ToolChain::addProfileRTLibs(Args, CmdArgs);
}
-llvm::DenormalMode
-Linux::getDefaultDenormalModeForType(const llvm::opt::ArgList ,
- const JobAction ,
- const llvm::fltSemantics *FPType) const {
- switch (getTriple().getArch()) {
andykaylor wrote:
So getDefaultDenormalModeForType() in ToolChain.h should be returning
DenormalMode::Dynamic() rather than DenormalMode::getIEEE(), right?
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] fast math test overhaul (PR #89687)
https://github.com/andykaylor closed https://github.com/llvm/llvm-project/pull/89687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] fast math test overhaul (PR #89687)
https://github.com/andykaylor updated https://github.com/llvm/llvm-project/pull/89687 >From 8c23afa9fd069fece39f3fa7a913d93aee082c77 Mon Sep 17 00:00:00 2001 From: Andy Kaylor Date: Tue, 23 Apr 2024 14:29:00 -0700 Subject: [PATCH] Clean up the checks in the fast-math driver test This change replaces most of the cc1 option checks in the driver test for fast-math option handling. These changes rely on the assumption that the order in which the driver emits floating-point options is stable. The changes also rely on the assumption that the order of prefixes listed on the FileCheck command line is unimportant and that all prefixed checks will be combined and checked as if they were a single prefix. At the time of the change, that worked. --- clang/test/Driver/fast-math.c | 333 -- 1 file changed, 159 insertions(+), 174 deletions(-) diff --git a/clang/test/Driver/fast-math.c b/clang/test/Driver/fast-math.c index 882e81fd14d34a..b07d5732932cdb 100644 --- a/clang/test/Driver/fast-math.c +++ b/clang/test/Driver/fast-math.c @@ -7,324 +7,309 @@ // Both of them use gcc driver for as. // // RUN: %clang -### -fno-honor-infinities -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s +// RUN: | FileCheck --check-prefixes=CHECK,NINF,NO-NNAN,NO-FINITE-ONLY %s // infinites [sic] is a supported alternative spelling of infinities. // RUN: %clang -### -fno-honor-infinites -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s -// CHECK-NO-INFS: "-cc1" -// CHECK-NO-INFS: "-menable-no-infs" +// RUN: | FileCheck --check-prefixes=CHECK,NINF,NO-NNAN,NO-FINITE-ONLY %s // // RUN: %clang -### -fno-fast-math -fno-honor-infinities -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-INFS %s -// CHECK-NO-FAST-MATH-NO-INFS: "-cc1" -// CHECK-NO-FAST-MATH-NO-INFS: "-menable-no-infs" +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NINF,NO-NNAN,NO-FINITE-ONLY %s // // RUN: %clang -### -fno-honor-infinities -fno-fast-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-INFS-NO-FAST-MATH %s -// CHECK-NO-INFS-NO-FAST-MATH: "-cc1" -// CHECK-NO-INFS-NO-FAST-MATH-NOT: "-menable-no-infs" +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NO-NINF,NO-NNAN,NO-FINITE-ONLY %s // // RUN: %clang -### -fno-signed-zeros -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-SIGNED-ZEROS %s -// CHECK-NO-SIGNED-ZEROS: "-cc1" -// CHECK-NO-SIGNED-ZEROS: "-fno-signed-zeros" +// RUN: | FileCheck --check-prefixes=CHECK,NSZ,NOROUNDING %s // // RUN: %clang -### -fno-fast-math -fno-signed-zeros -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS %s -// CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS: "-cc1" -// CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS: "-fno-signed-zeros" +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NSZ %s // // RUN: %clang -### -fno-signed-zeros -fno-fast-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH %s -// CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH: "-cc1" -// CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH-NOT: "-fno-signed-zeros" +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NO-NSZ,NOROUNDING %s // // RUN: %clang -### -freciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-RECIPROCAL-MATH %s -// CHECK-RECIPROCAL-MATH: "-cc1" -// CHECK-RECIPROCAL-MATH: "-freciprocal-math" +// RUN: | FileCheck --check-prefixes=CHECK,ARCP,NOROUNDING %s // // RUN: %clang -### -fno-fast-math -freciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-RECIPROCAL-MATH %s -// CHECK-NO-FAST-MATH-RECIPROCAL-MATH: "-cc1" -// CHECK-NO-FAST-MATH-RECIPROCAL-MATH: "-freciprocal-math" +// RUN: | FileCheck --check-prefixes=CHECK,ARCP,NOROUNDING %s // // RUN: %clang -### -freciprocal-math -fno-fast-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-RECIPROCAL-MATH-NO-FAST-MATH %s -// CHECK-RECIPROCAL-MATH-NO-FAST-MATH: "-cc1" -// CHECK-RECIPROCAL-MATH-NO-FAST-MATH-NOT: "-freciprocal-math" +// RUN: | FileCheck --check-prefixes=CHECK,NO-ARCP,NOROUNDING %s // // RUN: %clang -### -fno-honor-nans -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-NANS %s -// CHECK-NO-NANS: "-cc1" -// CHECK-NO-NANS: "-menable-no-nans" +// RUN: | FileCheck --check-prefixes=CHECK,NNAN,NO-NINF,NO-FINITE-ONLY,NOROUNDING %s // // RUN: %clang -### -fno-fast-math -fno-honor-nans -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-NANS %s -// CHECK-NO-FAST-MATH-NO-NANS: "-cc1" -// CHECK-NO-FAST-MATH-NO-NANS: "-menable-no-nans" +// RUN: | FileCheck --check-prefixes=CHECK,NO-FAST,NNAN,NO-NINF,NO-FINITE-ONLY,NOROUNDING %s // // RUN: %clang -### -fno-honor-nans -fno-fast-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-NANS-NO-FAST-MATH %s -// CHECK-NO-NANS-NO-FAST-MATH: "-cc1" -// CHECK-NO-NANS-NO-FAST-MATH-NOT: "-menable-no-nans" +// RUN: | FileCheck
[clang] fast math test overhaul (PR #89687)
andykaylor wrote: > I think this works for the test. I'm slightly confused by the PR not-stacking > with the test changes on top of the other PR That's user error on my part. There are commits here that I didn't intend to be part of this PR. I'll clean it up before I submit it. https://github.com/llvm/llvm-project/pull/89687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
andykaylor wrote: I've made extensive changes to the fast-math.c test here: https://github.com/llvm/llvm-project/pull/89687 That update isn't intended to change any existing behavior. A few things worked differently than I expected, but I left the checks consistent with the current behavior and added comments where I thought the current behavior was incorrect. https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] fast math test overhaul (PR #89687)
https://github.com/andykaylor created https://github.com/llvm/llvm-project/pull/89687 - Fix -fno-unsafe-math-optimizations behavior - [WIP] Major change to fast-math.c lit test - Clean up the checks in the fast-math driver test >From 100fc9dfb2b071877d758ce71bddeec693d986da Mon Sep 17 00:00:00 2001 From: Andy Kaylor Date: Fri, 19 Apr 2024 16:35:00 -0700 Subject: [PATCH 1/3] Fix -fno-unsafe-math-optimizations behavior 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 -ftrapping-math is enabled by default in gcc. Because clang does not enabled -ftrapping-math by default, there is no reason for -fno-unsafe-math-optimizations to set it. On the other hand, -funsafe-math-optimizations continues to imply -fno-trapping-math because this option necessarily disables strict exception semantics. This fixes https://github.com/llvm/llvm-project/issues/87523 --- clang/docs/UsersManual.rst| 1 - clang/lib/Driver/ToolChains/Clang.cpp | 2 -- clang/test/Driver/fast-math.c | 24 +--- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst index c464bc3a69adc5..2b4155d4b65a48 100644 --- a/clang/docs/UsersManual.rst +++ b/clang/docs/UsersManual.rst @@ -1690,7 +1690,6 @@ floating point semantic models: precise (the default), strict, and fast. * ``-fno-associative-math`` * ``-fno-reciprocal-math`` * ``-fsigned-zeros`` - * ``-ftrapping-math`` * ``-ffp-contract=on`` * ``-fdenormal-fp-math=ieee`` diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp index 456ea74caadb00..0776d095327219 100644 --- a/clang/lib/Driver/ToolChains/Clang.cpp +++ b/clang/lib/Driver/ToolChains/Clang.cpp @@ -3137,8 +3137,6 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , ReciprocalMath = false; SignedZeros = true; ApproxFunc = false; - TrappingMath = true; - FPExceptionBehavior = "strict"; // The target may have opted to flush by default, so force IEEE. DenormalFPMath = llvm::DenormalMode::getIEEE(); diff --git a/clang/test/Driver/fast-math.c b/clang/test/Driver/fast-math.c index 882e81fd14d34a..ef23f88dd817ea 100644 --- a/clang/test/Driver/fast-math.c +++ b/clang/test/Driver/fast-math.c @@ -271,11 +271,11 @@ // RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-reciprocal-math -c %s \ -// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: 2>&1 | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \ // RUN: -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s @@ -283,18 +283,20 @@ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-reciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-UNSAFE-MATH: "-cc1" // CHECK-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO_UNSAFE-MATH-NOT: "-mreassociate" +// CHECK-NO-UNSAFE-MATH-NOT: "-mreassociate" // CHECK-NO-UNSAFE-MATH: "-o" +// CHECK-NO-UNSAFE-MATH-NOT: "-ffp-exception-behavior=strict" +// CHECK-TRAPPING-NO-UNSAFE-MATH: "-ffp-exception-behavior=strict" // Reassociate is allowed because it does not require reciprocal-math. @@ -304,8 +306,8 @@ // RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // CHECK-REASSOC-NO-UNSAFE-MATH: "-cc1" -// CHECK-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-REASSOC-NO_UNSAFE-MATH: "-mreassociate" +// CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-REASSOC-NO-UNSAFE-MATH: "-mreassociate" // CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" // CHECK-REASSOC-NO-UNSAFE-MATH: "-o" @@ -318,12 +320,12 @@ // RUN: %clang
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
andykaylor wrote: I've made some minor changes to clean up the LIT test checks for this PR. I started to clean up the entire test, but it quickly became obvious that I should put that into a separate PR. I will submit a new PR to clean up the entire fast-math.c test. I have an idea that I think will work, hard-coding the order of the math-related flags and using a separate prefix for each one plus negative checks. Then the test can just use "--check-prefixes=..." to put together the combinations that are expected. I think that will be more maintainable and more readable than trying to group checks in the more-or-less arbitrary way the test currently does. https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
https://github.com/andykaylor updated https://github.com/llvm/llvm-project/pull/89473 >From 100fc9dfb2b071877d758ce71bddeec693d986da Mon Sep 17 00:00:00 2001 From: Andy Kaylor Date: Fri, 19 Apr 2024 16:35:00 -0700 Subject: [PATCH 1/2] Fix -fno-unsafe-math-optimizations behavior 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 -ftrapping-math is enabled by default in gcc. Because clang does not enabled -ftrapping-math by default, there is no reason for -fno-unsafe-math-optimizations to set it. On the other hand, -funsafe-math-optimizations continues to imply -fno-trapping-math because this option necessarily disables strict exception semantics. This fixes https://github.com/llvm/llvm-project/issues/87523 --- clang/docs/UsersManual.rst| 1 - clang/lib/Driver/ToolChains/Clang.cpp | 2 -- clang/test/Driver/fast-math.c | 24 +--- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst index c464bc3a69adc5..2b4155d4b65a48 100644 --- a/clang/docs/UsersManual.rst +++ b/clang/docs/UsersManual.rst @@ -1690,7 +1690,6 @@ floating point semantic models: precise (the default), strict, and fast. * ``-fno-associative-math`` * ``-fno-reciprocal-math`` * ``-fsigned-zeros`` - * ``-ftrapping-math`` * ``-ffp-contract=on`` * ``-fdenormal-fp-math=ieee`` diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp index 456ea74caadb00..0776d095327219 100644 --- a/clang/lib/Driver/ToolChains/Clang.cpp +++ b/clang/lib/Driver/ToolChains/Clang.cpp @@ -3137,8 +3137,6 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , ReciprocalMath = false; SignedZeros = true; ApproxFunc = false; - TrappingMath = true; - FPExceptionBehavior = "strict"; // The target may have opted to flush by default, so force IEEE. DenormalFPMath = llvm::DenormalMode::getIEEE(); diff --git a/clang/test/Driver/fast-math.c b/clang/test/Driver/fast-math.c index 882e81fd14d34a..ef23f88dd817ea 100644 --- a/clang/test/Driver/fast-math.c +++ b/clang/test/Driver/fast-math.c @@ -271,11 +271,11 @@ // RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-reciprocal-math -c %s \ -// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: 2>&1 | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \ // RUN: -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s @@ -283,18 +283,20 @@ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-reciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-UNSAFE-MATH: "-cc1" // CHECK-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO_UNSAFE-MATH-NOT: "-mreassociate" +// CHECK-NO-UNSAFE-MATH-NOT: "-mreassociate" // CHECK-NO-UNSAFE-MATH: "-o" +// CHECK-NO-UNSAFE-MATH-NOT: "-ffp-exception-behavior=strict" +// CHECK-TRAPPING-NO-UNSAFE-MATH: "-ffp-exception-behavior=strict" // Reassociate is allowed because it does not require reciprocal-math. @@ -304,8 +306,8 @@ // RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // CHECK-REASSOC-NO-UNSAFE-MATH: "-cc1" -// CHECK-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-REASSOC-NO_UNSAFE-MATH: "-mreassociate" +// CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-REASSOC-NO-UNSAFE-MATH: "-mreassociate" // CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" // CHECK-REASSOC-NO-UNSAFE-MATH: "-o" @@ -318,12 +320,12 @@ // RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \ // RUN: -fno-trapping-math -ftrapping-math -c %s 2>&1 \ -// RUN: |
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
@@ -318,12 +320,12 @@ // RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \ // RUN: -fno-trapping-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-REASSOC-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-REASSOC-NO-UNSAFE-MATH: "-cc1" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-mreassociate" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-mreassociate" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" andykaylor wrote: I'm not sure what this case was originally trying to do, but it seems that I can make CHECK, CHECK-NOT, and CHECK-SAME in a limited way. Specifically, CHECK-NOT doesn't reset the line used for CHECK-SAME. So if I have checks like this: ``` CHECK: foo CHECK-NOT: bar CHECK-SAME: fubar CHECK-NOT: bar ``` The string "foo fubar" will pass, the string "foo bar fubar" will fail the first CHECK-NOT test, and "foo fubar bar" will fail the second CHECK-NOT test. I think I can update this test such that it continues to use "-cc1" as the starting check for the options produced, and uses CHECK-SAME for the FP-related options it expects to be produced, and any options that should not be produced can be verified with a CHECK-NOT before and after the CHECK-SAME. https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)
andykaylor wrote: > This effort is highly desirable, c.f. this [blog > post](https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html), > so thanks for that! > > Xref: #57589, #80475, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 My patch here still leaves the problem that we're conflating the "denormal-fp-math" attribute with the desire to set FTZ/DAZ on startup. I think @jcranmer-intel's patch is more important because it actually does something about the shared library problem. Honestly, my goal here is quite different than what he's doing there. I want to make sure that we are setting FTZ+DAZ during startup when the application entry point is compiled with fast-math enabled. I'd like to eliminate the dependence on crtfastmath.o and set the flags in the FP control register directly in main() when that's what we intended. I'm not sure what the correct behavior is across all platforms. My perspective on this is heavily X86-biased, so I'd really like some guidance from people who work on other targets about their expectations. I think I saw at least one target that sets denormal-fp-math=preservesign as their default even without any fast-math options enabled. It wouldn't surprise me if there are targets that don't want to set denormal-fp-math=preservesign even with fast-math. For some(?) Linux targets, we've got the mess I'm touching here where the driver is looking for crtfastmath.o and trying to inspect the command-line for fast-math settings outside the other FP option rendering, and then the FP option rendering, which is meant to be target-independent, is kind of making a mess of it, especially with inconsistent handling of "denormal-fp-math" and "denormal-fp32-math". https://github.com/llvm/llvm-project/pull/89477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
@@ -318,12 +320,12 @@ // RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \ // RUN: -fno-trapping-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-REASSOC-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-REASSOC-NO-UNSAFE-MATH: "-cc1" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-mreassociate" -// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-mreassociate" +// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" andykaylor wrote: I'd be happy to make that change. I was a little lazy with this test. I just wanted something that tested the change I was making, and then the rest of what I did was just what seemed necessary to make the test pass while still testing the things it meant to test. The whole thing seemed a bit of a mess. I can clean it up some with a bit more effort. https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
@@ -271,30 +271,32 @@ // RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-reciprocal-math -c %s \ -// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: 2>&1 | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \ // RUN: -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-reciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-UNSAFE-MATH: "-cc1" // CHECK-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO_UNSAFE-MATH-NOT: "-mreassociate" andykaylor wrote: At least this one was broken, which I think was indicated by the underscore in the check line. Many of the others are at least insufficient. https://github.com/llvm/llvm-project/pull/89473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)
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-math and -ffp-contract=fast." That isn't entirely correct.
One difference is that -ffast-math causes crtfastmath.o to be linked if
it is available, and passes -fdenormal-fp-math=PreserveSign as a -cc1
option when crtfastmath.o is available.
I'm not sure the current behavior is reasonable and consistent for all
tool chains, but I'm not trying to fix that here. This is just trying to
make an incremental improvement.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
>From cd8df1939a456c05a1d94c471627fc5a7a332fc1 Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH] Align -ffp-model=fast denormal handling with -ffast-math
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-math and -ffp-contract=fast." That isn't entirely correct.
One difference is that -ffast-math causes crtfastmath.o to be linked if
it is available, and passes -fdenormal-fp-math=PreserveSign as a -cc1
option when crtfastmath.o is available.
I'm not sure the current behavior is reasonable and consistent for all
tool chains, but I'm not trying to fix that here. This is just trying to
make an incremental improvement.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
clang/docs/UsersManual.rst | 4 ++--
clang/lib/Driver/ToolChain.cpp | 8 +++-
clang/lib/Driver/ToolChains/Clang.cpp| 4
clang/test/Driver/default-denormal-fp-math.c | 3 +++
clang/test/Driver/linux-ld.c | 3 +++
clang/test/Driver/solaris-ld.c | 3 +++
6 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index c464bc3a69adc5..00bb1e779308ef 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default),
strict, and fast.
"fenv_access", "off", "on", "off"
"rounding_mode", "tonearest", "dynamic", "tonearest"
"contract", "on", "off", "fast"
- "denormal_fp_math", "IEEE", "IEEE", "IEEE"
- "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+ "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+ "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
"support_math_errno", "on", "on", "off"
"no_honor_nans", "off", "off", "on"
"no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 237092ed07e5dc..a36d8eb1750a2d 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1314,11 +1314,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const
ArgList ,
Arg *A =
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
options::OPT_funsafe_math_optimizations,
- options::OPT_fno_unsafe_math_optimizations);
+ options::OPT_fno_unsafe_math_optimizations,
+ options::OPT_ffp_model_EQ);
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
return false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+ StringRef Model = A->getValue();
+ if (!Model.equals("fast"))
+return false;
+}
}
// If crtfastmath.o exists add it to the arguments.
Path = GetFilePath("crtfastmath.o");
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 456ea74caadb00..0ee74855891b03 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2942,6 +2942,10 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
if (Val.equals("fast")) {
FPModel = Val;
applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
diff --git
[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)
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 -ftrapping-math is enabled by default in gcc. Because clang does not enabled -ftrapping-math by default, there is no reason for -fno-unsafe-math-optimizations to set it. On the other hand, -funsafe-math-optimizations continues to imply -fno-trapping-math because this option necessarily disables strict exception semantics. This fixes https://github.com/llvm/llvm-project/issues/87523 >From 100fc9dfb2b071877d758ce71bddeec693d986da Mon Sep 17 00:00:00 2001 From: Andy Kaylor Date: Fri, 19 Apr 2024 16:35:00 -0700 Subject: [PATCH] Fix -fno-unsafe-math-optimizations behavior 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 -ftrapping-math is enabled by default in gcc. Because clang does not enabled -ftrapping-math by default, there is no reason for -fno-unsafe-math-optimizations to set it. On the other hand, -funsafe-math-optimizations continues to imply -fno-trapping-math because this option necessarily disables strict exception semantics. This fixes https://github.com/llvm/llvm-project/issues/87523 --- clang/docs/UsersManual.rst| 1 - clang/lib/Driver/ToolChains/Clang.cpp | 2 -- clang/test/Driver/fast-math.c | 24 +--- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst index c464bc3a69adc5..2b4155d4b65a48 100644 --- a/clang/docs/UsersManual.rst +++ b/clang/docs/UsersManual.rst @@ -1690,7 +1690,6 @@ floating point semantic models: precise (the default), strict, and fast. * ``-fno-associative-math`` * ``-fno-reciprocal-math`` * ``-fsigned-zeros`` - * ``-ftrapping-math`` * ``-ffp-contract=on`` * ``-fdenormal-fp-math=ieee`` diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp index 456ea74caadb00..0776d095327219 100644 --- a/clang/lib/Driver/ToolChains/Clang.cpp +++ b/clang/lib/Driver/ToolChains/Clang.cpp @@ -3137,8 +3137,6 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , ReciprocalMath = false; SignedZeros = true; ApproxFunc = false; - TrappingMath = true; - FPExceptionBehavior = "strict"; // The target may have opted to flush by default, so force IEEE. DenormalFPMath = llvm::DenormalMode::getIEEE(); diff --git a/clang/test/Driver/fast-math.c b/clang/test/Driver/fast-math.c index 882e81fd14d34a..ef23f88dd817ea 100644 --- a/clang/test/Driver/fast-math.c +++ b/clang/test/Driver/fast-math.c @@ -271,11 +271,11 @@ // RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-reciprocal-math -c %s \ -// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: 2>&1 | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \ // RUN: -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s @@ -283,18 +283,20 @@ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-reciprocal-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fsigned-zeros -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \ -// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s +// RUN: | FileCheck --check-prefix=CHECK-TRAPPING-NO-UNSAFE-MATH %s // RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \ // RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s // CHECK-NO-UNSAFE-MATH: "-cc1" // CHECK-NO-UNSAFE-MATH-NOT: "-funsafe-math-optimizations" -// CHECK-NO_UNSAFE-MATH-NOT: "-mreassociate" +// CHECK-NO-UNSAFE-MATH-NOT: "-mreassociate" // CHECK-NO-UNSAFE-MATH: "-o" +// CHECK-NO-UNSAFE-MATH-NOT: "-ffp-exception-behavior=strict" +// CHECK-TRAPPING-NO-UNSAFE-MATH: "-ffp-exception-behavior=strict" // Reassociate is allowed because it does not require reciprocal-math. @@ -304,8 +306,8 @@ // RUN: | FileCheck
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
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/listinfo/cfe-commits
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
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=X86WINPRMTD // RUN: %clang_cc1 -triple=avr-unknown-unknown -mdouble=32 \ // RUN: -complex-range=promoted -emit-llvm -o - %s \ // RUN: | FileCheck %s --check-prefix=AVRFP32 // RUN: %clang_cc1 -triple=avr-unknown-unknown -mdouble=64 \ // RUN: -complex-range=promoted -emit-llvm -o - %s \ // RUN: | FileCheck %s --check-prefix=AVRFP64 ``` 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+const auto *CurrentBT = dyn_cast(ElementType);
+switch (CurrentBT->getKind()) {
+case BuiltinType::Kind::Float16:
+ return CGF.getContext().FloatTy;
+case BuiltinType::Kind::Float:
+case BuiltinType::Kind::BFloat16:
+ return CGF.getContext().DoubleTy;
+case BuiltinType::Kind::Double:
+ return CGF.getContext().LongDoubleTy;
+default:
+ return ElementType;
+}
+ }
+
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType,
+ bool IsDivOpCode) {
+QualType HigherElementType = GetHigherPrecisionFPType(ElementType);
+const llvm::fltSemantics =
+CGF.getContext().getFloatTypeSemantics(ElementType);
+const llvm::fltSemantics =
+CGF.getContext().getFloatTypeSemantics(HigherElementType);
+if (llvm::APFloat::semanticsMaxExponent(ElementTypeSemantics) * 2 + 1 <=
+llvm::APFloat::semanticsMaxExponent(HigherElementTypeSemantics)) {
+ return CGF.getContext().getComplexType(HigherElementType);
+} else {
+ FPHasBeenPromoted = LangOptions::ComplexRangeKind::CX_Improved;
andykaylor wrote:
Can you add a test for this case?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
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.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -2824,26 +2816,89 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
switch (optID) {
default:
break;
-case options::OPT_fcx_limited_range: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Limited);
- Range = LangOptions::ComplexRangeKind::CX_Limited;
+case options::OPT_fcx_limited_range:
+ if (GccRangeComplexOption.empty()) {
+if (Range != LangOptions::ComplexRangeKind::CX_Basic)
+ EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fcx-limited-range");
+ } else {
+if (GccRangeComplexOption != "-fno-cx-limited-range")
+ EmitComplexRangeDiag(D, GccRangeComplexOption, "-fcx-limited-range");
+ }
+ GccRangeComplexOption = "-fcx-limited-range";
+ Range = LangOptions::ComplexRangeKind::CX_Basic;
break;
-}
case options::OPT_fno_cx_limited_range:
- EmitComplexRangeDiag(D, Range, LangOptions::ComplexRangeKind::CX_Full,
- "-fno-cx-limited-range");
+ if (GccRangeComplexOption.empty()) {
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fno-cx-limited-range");
+ } else {
+if (GccRangeComplexOption.compare("-fcx-limited-range") != 0 &&
+GccRangeComplexOption.compare("-fno-cx-fortran-rules") != 0)
+ EmitComplexRangeDiag(D, GccRangeComplexOption,
+ "-fno-cx-limited-range");
+ }
+ GccRangeComplexOption = "-fno-cx-limited-range";
Range = LangOptions::ComplexRangeKind::CX_Full;
break;
-case options::OPT_fcx_fortran_rules: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Fortran);
- Range = LangOptions::ComplexRangeKind::CX_Fortran;
+case options::OPT_fcx_fortran_rules:
+ if (GccRangeComplexOption.empty())
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fcx-fortran-rules");
+ else
+EmitComplexRangeDiag(D, GccRangeComplexOption, "-fcx-fortran-rules");
+ GccRangeComplexOption = "-fcx-fortran-rules";
+ Range = LangOptions::ComplexRangeKind::CX_Improved;
break;
-}
case options::OPT_fno_cx_fortran_rules:
- EmitComplexRangeDiag(D, Range, LangOptions::ComplexRangeKind::CX_Full,
- "-fno-cx-fortran-rules");
+ if (GccRangeComplexOption.empty()) {
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fno-cx-fortran-rules");
+ } else {
+if (GccRangeComplexOption != "-fno-cx-limited-range")
+ EmitComplexRangeDiag(D, GccRangeComplexOption,
+ "-fno-cx-fortran-rules");
+ }
+ GccRangeComplexOption = "-fno-cx-fortran-rules";
Range = LangOptions::ComplexRangeKind::CX_Full;
break;
+case options::OPT_fcomplex_arithmetic_EQ: {
+ LangOptions::ComplexRangeKind RangeVal;
+ StringRef Val = A->getValue();
+ if (Val.equals("full"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Full;
+ else if (Val.equals("improved"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Improved;
+ else if (Val.equals("promoted"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Promoted;
+ else if (Val.equals("basic"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Basic;
+ else
+D.Diag(diag::err_drv_unsupported_option_argument)
+<< A->getSpelling() << LangOptions::ComplexRangeKind::CX_None;
+ if (GccRangeComplexOption.empty() && !SeenUnsafeMathModeOption) {
andykaylor wrote:
I thought @AaronBallman had suggested that we shouldn't warn in that case since
the same base option is being used and the user is likely to have intended it.
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -794,8 +834,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo ) {
ResR = Builder.CreateFSub(AC, BD, "mul_r");
ResI = Builder.CreateFAdd(AD, BC, "mul_i");
- if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited ||
- Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+ if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Basic ||
+ Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved ||
+ Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted ||
+ CGF.getLangOpts().NoHonorInfs || CGF.getLangOpts().NoHonorNaNs)
andykaylor wrote:
Oh, sorry, for some reason I thought this was invoking the special handling for
division. I think the for honor NaNs and infinities still isn't necessary
because we'll emit the comparison with the fast-math flags set and the backend
will optimize it away, which is what happens today:
https://godbolt.org/z/e8EnKodj6
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -986,13 +1028,17 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo ) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+QualType ComplexElementTy = Op.Ty->castAs()->getElementType();
+if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved ||
+(Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted &&
+ FPHasBeenPromoted == LangOptions::CX_Improved))
return EmitRangeReductionDiv(LHSr, LHSi, RHSr, RHSi);
-else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited)
+else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Basic ||
+ Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted)
return EmitAlgebraicDiv(LHSr, LHSi, RHSr, RHSi);
else if (!CGF.getLangOpts().FastMath ||
andykaylor wrote:
I think we should remove the fast-math check here. The driver handling of
fast-math sets the complex arithmetic option. This check has always been
problematic because disabling just one component of fast-math (such as enabling
signed zeros) causes this to be false.
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -2824,26 +2816,89 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
switch (optID) {
default:
break;
-case options::OPT_fcx_limited_range: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Limited);
- Range = LangOptions::ComplexRangeKind::CX_Limited;
+case options::OPT_fcx_limited_range:
+ if (GccRangeComplexOption.empty()) {
+if (Range != LangOptions::ComplexRangeKind::CX_Basic)
+ EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fcx-limited-range");
+ } else {
+if (GccRangeComplexOption != "-fno-cx-limited-range")
+ EmitComplexRangeDiag(D, GccRangeComplexOption, "-fcx-limited-range");
+ }
+ GccRangeComplexOption = "-fcx-limited-range";
+ Range = LangOptions::ComplexRangeKind::CX_Basic;
break;
-}
case options::OPT_fno_cx_limited_range:
- EmitComplexRangeDiag(D, Range, LangOptions::ComplexRangeKind::CX_Full,
- "-fno-cx-limited-range");
+ if (GccRangeComplexOption.empty()) {
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fno-cx-limited-range");
+ } else {
+if (GccRangeComplexOption.compare("-fcx-limited-range") != 0 &&
+GccRangeComplexOption.compare("-fno-cx-fortran-rules") != 0)
+ EmitComplexRangeDiag(D, GccRangeComplexOption,
+ "-fno-cx-limited-range");
+ }
+ GccRangeComplexOption = "-fno-cx-limited-range";
Range = LangOptions::ComplexRangeKind::CX_Full;
break;
-case options::OPT_fcx_fortran_rules: {
- EmitComplexRangeDiag(D, Range,
LangOptions::ComplexRangeKind::CX_Fortran);
- Range = LangOptions::ComplexRangeKind::CX_Fortran;
+case options::OPT_fcx_fortran_rules:
+ if (GccRangeComplexOption.empty())
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fcx-fortran-rules");
+ else
+EmitComplexRangeDiag(D, GccRangeComplexOption, "-fcx-fortran-rules");
+ GccRangeComplexOption = "-fcx-fortran-rules";
+ Range = LangOptions::ComplexRangeKind::CX_Improved;
break;
-}
case options::OPT_fno_cx_fortran_rules:
- EmitComplexRangeDiag(D, Range, LangOptions::ComplexRangeKind::CX_Full,
- "-fno-cx-fortran-rules");
+ if (GccRangeComplexOption.empty()) {
+EmitComplexRangeDiag(D, RenderComplexRangeOption(Range),
+ "-fno-cx-fortran-rules");
+ } else {
+if (GccRangeComplexOption != "-fno-cx-limited-range")
+ EmitComplexRangeDiag(D, GccRangeComplexOption,
+ "-fno-cx-fortran-rules");
+ }
+ GccRangeComplexOption = "-fno-cx-fortran-rules";
Range = LangOptions::ComplexRangeKind::CX_Full;
break;
+case options::OPT_fcomplex_arithmetic_EQ: {
+ LangOptions::ComplexRangeKind RangeVal;
+ StringRef Val = A->getValue();
+ if (Val.equals("full"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Full;
+ else if (Val.equals("improved"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Improved;
+ else if (Val.equals("promoted"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Promoted;
+ else if (Val.equals("basic"))
+RangeVal = LangOptions::ComplexRangeKind::CX_Basic;
+ else
+D.Diag(diag::err_drv_unsupported_option_argument)
+<< A->getSpelling() << LangOptions::ComplexRangeKind::CX_None;
+ if (GccRangeComplexOption.empty() && !SeenUnsafeMathModeOption) {
andykaylor wrote:
I'm not clear what this is doing. Is this warning for things like
"-fcomplex-arithmetic=full -fcomplex-arithmetic=basic"?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -986,13 +1028,17 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo ) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+QualType ComplexElementTy = Op.Ty->castAs()->getElementType();
+if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved ||
+(Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted &&
+ FPHasBeenPromoted == LangOptions::CX_Improved))
andykaylor wrote:
It seems that this value is only ever set to CX_Improved or CX_None. Why not
use a Boolean? As it is, I'm left with questions about what would happen if the
value were CX_Basic or CX_None (expecting that CX_Promoted would be used if we
did promote).
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -2807,9 +2791,17 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , FPExceptionBehavior = ""; // If fast-math is set then set the fp-contract mode to fast. FPContract = "fast"; -// ffast-math enables limited range rules for complex multiplication and +// ffast-math enables basic range rules for complex multiplication and andykaylor wrote: We may have a naming problem here. The term "limited range rules" has a direct definition in the C standard, whereas "basic range rules" is essentially our construct to get the same behavior. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -794,8 +834,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo ) {
ResR = Builder.CreateFSub(AC, BD, "mul_r");
ResI = Builder.CreateFAdd(AD, BC, "mul_i");
- if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited ||
- Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+ if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Basic ||
+ Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved ||
+ Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted ||
+ CGF.getLangOpts().NoHonorInfs || CGF.getLangOpts().NoHonorNaNs)
andykaylor wrote:
I'm not sure NoHonorInfs or NoHonorNaNs should be checked here. Given that we
have explicit control for complex arithmetic behavior, maybe that should take
precedence. That seems to be the way gcc handles it:
https://godbolt.org/z/1oGo7jznz
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -51,11 +51,12 @@ class ComplexExprEmitter
CGBuilderTy
bool IgnoreReal;
bool IgnoreImag;
-public:
- ComplexExprEmitter(CodeGenFunction , bool ir=false, bool ii=false)
-: CGF(cgf), Builder(CGF.Builder), IgnoreReal(ir), IgnoreImag(ii) {
- }
+ LangOptions::ComplexRangeKind FPHasBeenPromoted;
andykaylor wrote:
This is a somewhat misleading variable name. The name implies that it will be a
Boolean value.
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -2807,9 +2791,17 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , FPExceptionBehavior = ""; // If fast-math is set then set the fp-contract mode to fast. FPContract = "fast"; -// ffast-math enables limited range rules for complex multiplication and +// ffast-math enables basic range rules for complex multiplication and // division. -Range = LangOptions::ComplexRangeKind::CX_Limited; +// Warn if user expects to perform full implementation of complex +// multiplication or division in the presence of nnan or ninf flags. +if (Range == LangOptions::ComplexRangeKind::CX_Full) andykaylor wrote: Shouldn't we also warn if this is overriding promoted or improved? 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm + at source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate + calculations, but overflow may occur. NaN and infinite values are not + handled in some cases. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled by the + library implementation. For the case of multiplication overflow will occur in + accordance with normal floating-point rules. This is the default value. + * ``promoted`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. Non-finite values are handled in some + cases. If the target does not have native support for a higher precision + data type, an implementation for the complex operation will be used to provide + improved guards against intermediate overflow, but overflow and underflow may + still occur in some cases. NaN and infinite values are not handled. andykaylor wrote: The intention here was that if the target doesn't support a higher precision type, we will do what we would have done with "improved". Some targets don't even support a 64-bit floating-point type, so the way we apply this needs to be generalized. Should we issue a warning if the user specifies "promoted" but we can't promote? Zahira and I talked about this offline, and my suggestion was that if LongDoubleSize is greater than DoubleSize, we can promote double to long double, but if it isn't we will use the Smith algorithm (i.e. "improved"). Windows on x86-64 is the really ugly case here, because the target hardware supports an 80-bit floating-point type, but by default the operating system configures the x87 layer to perform calculations as if it were a 64-bit type. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType,
+ bool IsDivOpCode) {
+const TargetInfo = CGF.getContext().getTargetInfo();
+const LangOptions Opts = CGF.getLangOpts();
+if (const auto *BT = dyn_cast(ElementType)) {
+ switch (BT->getKind()) {
+ case BuiltinType::Kind::Float16: {
+if (TI.hasFloat16Type() && !TI.hasLegalHalfType())
+ return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+break;
+ }
+ case BuiltinType::Kind::BFloat16: {
+if (TI.hasBFloat16Type() && !TI.hasFullBFloat16Type())
+ return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+break;
+ }
+ case BuiltinType::Kind::Float:
+return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
+break;
+ case BuiltinType::Kind::Double: {
+if (TI.hasLongDoubleType())
+ return
CGF.getContext().getComplexType(CGF.getContext().LongDoubleTy);
+return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
andykaylor wrote:
Yes, we need to check the sizes. If we "promote" from a 64-bit double to a
64-bit long double, we'll probably end up with something that gets optimized
directly to the cx-limited-range ("basic") implementation. This can also be an
issue for float. For example, AVR targets use a 32-bit type for both float and
double.
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some + cases. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled by the + library implementation. + * ``promoted`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. Non-finite values are handled in some + cases. If the target hardware does not have native support for a higher precision + data type, an implementation for the complex operation will be used to provide + improved guards against intermediate overflow, but overflow and underflow may + still occur in some cases. NaN and infinite and values are not handled. + This is the default value. andykaylor wrote: I see that gcc uses a runtime library call with both c89 and c99. That seems like a reasonable way to go. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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<["-"], "fcx-limited-range">, andykaylor wrote: What I meant to suggest is that you can leave the driver-level options as if they were independent, but when we process them in RenderFloatingPointOptions, -fcx-limited-range and -fcomplex-arithmetic=basic (for example), would add the same cc1 option. Since the warning is generated from the RenderFloatingPointOptions we should be able to make that report the expected output. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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<["-"], "fcx-limited-range">, andykaylor wrote: Sorry. I meant "aliasing" in the non-technical sense of "having the same meaning." How that gets implemented is another matter. I think the driver could translate them to the same cc1 option. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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
- // LMTD-NEXT: fadd float
- // LMTD-NEXT: fmul float
- // LMTD-NEXT: fmul float
- // LMTD-NEXT: fsub float
- // 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 float
- // FRTRN-NEXT: fadd float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fsub float
- // FRTRN-NEXT: fdiv float
- // FRTRN-NEXT: fdiv float
+ // BASIC: fmul float
+ // BASIC-NEXT: fmul float
+ // BASIC-NEXT: fadd float
+ // BASIC-NEXT: fmul float
+ // BASIC-NEXT: fmul float
+ // BASIC-NEXT: fadd float
+ // BASIC-NEXT: fmul float
+ // BASIC-NEXT: fmul float
+ // BASIC-NEXT: fsub float
+ // BASIC-NEXT: fdiv float
+ // BASIC-NEXT: fdiv float
+
+ // IMPRVD: fmul float
+ // IMPRVD-NEXT: fmul float
+ // IMPRVD-NEXT: fadd float
+ // IMPRVD-NEXT: fmul float
+ // IMPRVD-NEXT: fmul float
+ // IMPRVD-NEXT: fadd float
+ // IMPRVD-NEXT: fmul float
+ // IMPRVD-NEXT: fmul float
+ // IMPRVD-NEXT: fsub float
+ // IMPRVD-NEXT: fdiv float
+ // IMPRVD-NEXT: fdiv float
+
+ // PRMTD: fpext float {{.*}} to double
andykaylor wrote:
Shouldn't the pragma override the need to extend in this case?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType,
+ bool IsDivOpCode) {
+const TargetInfo = CGF.getContext().getTargetInfo();
+if (const auto *BT = dyn_cast(ElementType)) {
+ switch (BT->getKind()) {
+ case BuiltinType::Kind::Float16:
+ case BuiltinType::Kind::BFloat16: {
+return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+ }
+ case BuiltinType::Kind::Float:
+return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
+ case BuiltinType::Kind::Double:
+if (TI.hasLongDoubleType()) {
+ return
CGF.getContext().getComplexType(CGF.getContext().LongDoubleTy);
+} else {
+ return QualType();
+}
+ case BuiltinType::Kind::LongDouble:
andykaylor wrote:
This is more complicated than what you have here. The C "long double" type may
be 64-bit, 80-bit, or 128-bit, depending on the target. You can get the size
from LangOpts::LongDoubleSize if that's accessible here.
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some andykaylor wrote: "but overflow may occur" -- I'm getting a little bit over my head here, but I think the academic papers for the Smith algorithm say that it underflows but doesn't overflow. Or maybe that was a description of an improvement to Smith that I came across. If we're going to be technical here, we should be sure that our wording is accurate. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some + cases. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled by the + library implementation. andykaylor wrote: In the case of multiplication, the library call is only needed to handle non-finite values. Overflow occurs in accordance with normal floating-point rules. That is, even if we promoted to a higher precision type, the same overflow would occur when we truncate back to the source type. This isn't true for division because of the nature of the intermediate calculations. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some + cases. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled by the + library implementation. + * ``promoted`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. Non-finite values are handled in some + cases. If the target hardware does not have native support for a higher precision andykaylor wrote: ```suggestion cases. If the target does not have native support for a higher precision ``` I suggest removing "hardware" since the target may be SPIRV with unknown hardware. I'm not sure what we should do in the case of soft-float targets. Probably "full" makes most sense there, but I'd like to hear from someone who works with one of those targets. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType,
+ bool IsDivOpCode) {
+const TargetInfo = CGF.getContext().getTargetInfo();
+if (const auto *BT = dyn_cast(ElementType)) {
+ switch (BT->getKind()) {
+ case BuiltinType::Kind::Float16:
+ case BuiltinType::Kind::BFloat16: {
+return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+ }
+ case BuiltinType::Kind::Float:
+return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
+ case BuiltinType::Kind::Double:
+if (TI.hasLongDoubleType()) {
andykaylor wrote:
What happens with targets where double and long double are the same size?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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<["-"], "fcx-limited-range">, andykaylor wrote: I didn't realize these had made it into the 18.0 release when I suggested that we could remove them. We would need at least one release where they are marked as deprecated, but since they are standard gcc options, maybe it makes sense to just keep them and have them alias to the new option as: -fcx-limited-range --> -fcomplex-arithmetic=basic -fcx-fortran-rules --> -fcomplex-arithmetic=improved -fno-cx-limited-range --> -fcomplex-arithmetic=full -fno-cx-fortran-rules --> -fcomplex-arithmetic=full 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some + cases. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled by the + library implementation. + * ``promoted`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. Non-finite values are handled in some + cases. If the target hardware does not have native support for a higher precision + data type, an implementation for the complex operation will be used to provide + improved guards against intermediate overflow, but overflow and underflow may + still occur in some cases. NaN and infinite and values are not handled. + This is the default value. andykaylor wrote: I think for many users this would make sense as the default value, but "full" is required for conformance to the C standard. Can we use this as the default if we're targeting pre-C99 but use "full" with C99 and later? I'm not sure what C++ expects, but probably "full" there too. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + This value offers improved handling for overflow in intermediate calculations, + but overflow may occur. NaN and infinite and values are not handled in some + cases. + * ``full`` Implementation of complex division and multiplication using a andykaylor wrote: What are we doing with fast-math flags in these expansions? In the case of complex multiplication, if the 'nnan' and 'ninf' flags are set on the generated instructions, the "full" implementation will be optimized to the "basic" implementation. I think that's probably what we want since "full" is going to be the default. It may warrant a warning if we see an explicit "-fcomplex-arithmetic=full" on the command line with any of the options that sets either 'nnan' or 'ninf'. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 float
- // FRTRN-NEXT: fadd float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fmul float
- // FRTRN-NEXT: fsub float
- // FRTRN-NEXT: fdiv float
- // FRTRN-NEXT: fdiv float
+ // SMITH: fmul float
+ // SMITH-NEXT: fmul float
+ // SMITH-NEXT: fadd float
+ // SMITH-NEXT: fmul float
+ // SMITH-NEXT: fmul float
+ // SMITH-NEXT: fadd float
+ // SMITH-NEXT: fmul float
+ // SMITH-NEXT: fmul float
+ // SMITH-NEXT: fsub float
+ // SMITH-NEXT: fdiv float
+ // SMITH-NEXT: fdiv float
+
+ // EXTND: fpext float {{.*}} to double
+ // EXTND: fpext float {{.*}} to double
+ // EXTND: fmul double
+ // EXTND: fmul double
+ // EXTND: fadd double
+ // EXTND: fmul double
+ // EXTND: fmul double
+ // EXTND: fadd double
+ // EXTND: fmul double
+ // EXTND: fmul double
+ // EXTND: fsub double
+ // EXTND: fdiv double
+ // EXTND: fdiv double
+ // EXTND: fptrunc double
+ // EXTND: fptrunc double
return a / b;
}
_Complex float pragma_off_div(_Complex float a, _Complex float b) {
#pragma STDC CX_LIMITED_RANGE OFF
// LABEL: define {{.*}} @pragma_off_div(
+
// FULL: call {{.*}} @__divsc3
// LMTD: call {{.*}} @__divsc3
- // FRTRN: call {{.*}} @__divsc3
+ // SMITH: call {{.*}} @__divsc3
+
+ // EXTND: call {{.*}} @__divdc3
+
+ return a / b;
+}
+
+_Complex float pragma_default_mul(_Complex float a, _Complex float b) {
+#pragma STDC CX_LIMITED_RANGE DEFAULT
+ // LABEL: define {{.*}} @pragma_on_mul(
+
+ // FULL: fmul float
+ // FULL-NEXT: fmul float
+ // FULL-NEXT: fmul float
+ // FULL-NEXT: fmul float
+ // FULL-NEXT: fsub float
+ // FULL-NEXT: fadd float
andykaylor wrote:
Shouldn't there be a check for NaN comparisons and a library call in this case?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``. + + * ``basic`` Implementation of complex division and multiplication using + algebraic formulas at source precision. No special handling to avoid + overflow. NaN and infinite and values are not handled. + * ``improved`` Implementation of complex division using the Smith algorithm at andykaylor wrote: I'm not sure we should document this as being implemented using the Smith algorithm. That may be left as an implementation detail, particularly if we start generating intrinsics which are handled in the backend or by an offload target. I would prefer to just describe the characteristics this option is intended to provide -- improved handling for overflow, but no special handling for the "NaN + NaNi" cases. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 {
+/// Implementation of complex division and multiplication using a call to
+/// runtime library functions(generally the case, but the BE might
+/// sometimes replace the library call if it knows enough about the
+/// potential range of the inputs). Overflow and non -finite values are
+/// handled by the library implementation.
+CX_Full,
+
+/// Implementation of complex division using the Smith algorithm at
+/// source precision. Smith's algorithm for complex division.
+/// See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8
+/// (1962). This value offers improved handling for overflow in
intermediate
+/// calculations, but overflow may occur. NaN and infinite and values are
+/// not handled in some cases.
+CX_Improved,
+
+/// Implementation of complex division using algebraic formulas at
+/// higher precision. Overflow is handled. Non-finite values are handled in
+/// some cases. If the target hardware does not have native support for a
+/// higher precision data type, an implementation for the complex operation
+/// will be used to provide improved guards against intermediate overflow,
+/// but overflow and underflow may still occur in some cases. NaN and
+/// infinite and values are not handled. This is the default value.
+CX_Promoted,
+
+/// Implementation of complex division and multiplication using
+/// algebraic formulas at source precision.No special handling to avoid
andykaylor wrote:
```suggestion
/// algebraic formulas at source precision. No special handling to avoid
```
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values + are not handled. + * ``smith`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + Overflow is handled. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled. andykaylor wrote: ```suggestion range of the inputs). Overflow and non-finite values are handled by the library implementation. ``` I want to emphasize the location of the handling because I found a case where the current LLVM library function overflows with complex division. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values + are not handled. + * ``smith`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + Overflow is handled. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled. + * ``extend`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. andykaylor wrote: You should specify that "full" is the default. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values + are not handled. + * ``smith`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + Overflow is handled. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled. + * ``extend`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. andykaylor wrote: Again, explicitly mention that non-finite values are not handled in all cases. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values andykaylor wrote: I don't think it's accurate to say that "non-finite values are not handled." I would say instead that infinite values are not handled correctly in all cases. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values + are not handled. + * ``smith`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + Overflow is handled. + * ``full`` Implementation of complex division and multiplication using a + call to runtime library functions (generally the case, but the BE might + sometimes replace the library call if it knows enough about the potential + range of the inputs). Overflow and non-finite values are handled. + * ``extend`` Implementation of complex division using algebraic formulas at + higher precision. Overflow is handled. andykaylor wrote: It is probably worth adding an example to illustrate both the overflow and non-finite handling cases so users can properly understand the risk of ignoring those cases. 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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -283,9 +283,23 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType getPromotionType(QualType Ty, bool IsDivOpCode = false) {
if (auto *CT = Ty->getAs()) {
QualType ElementType = CT->getElementType();
+ if (CGF.getLangOpts().getComplexRange() ==
+ LangOptions::ComplexRangeKind::CX_Extend &&
+ IsDivOpCode) {
+if (ElementType->isFloatingType()) {
+ if (const auto *BT = dyn_cast(ElementType))
+switch (BT->getKind()) {
+case BuiltinType::Kind::Float:
+ return
CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
+default:
andykaylor wrote:
This doesn't look general enough. I'm not sure how to implement this. We need
some handling for fp16 and fp128. I guess fp16 would promote to float, but
fp128 will require using runtime library calls. For Windows, double and long
double are the same by default. Does the front end have a way to specifically
recognize x86_fp80 and ppc_fp128? Will something in Sema prevent us from
getting here with bf16?
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
[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)
@@ -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 mathematical formulas for complex division and - multiplication with no NaN checking of results. The default is - ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` - option. - -.. option:: -fcx-fortran-rules: - - This option enables the naive mathematical formulas for complex - multiplication and enables application of Smith's algorithm for complex - division. See SMITH, R. L. Algorithm 116: Complex division. Commun. - ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. +.. option:: -fcomplex-arithmetic=: + + This option specifies the implementation for complex multiplication and division. + + Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. + + * ``limited`` Implementation of complex division and multiplication using + algebraic formulas at source precision. Overflow and non-finites values + are not handled. + * ``smith`` Implementation of complex division using the Smith algorithm at + source precision. Smith's algorithm for complex division. + See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). + Overflow is handled. andykaylor wrote: There are some cases at the extreme end of the value range where overflow can still occur. I think this should say that it offers improved handling for overflow in intermediate calculations, but mention that overflow is still possible. We should also mention that this does not handle non-finite values in all cases. 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
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
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
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
@@ -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 compiled with ``-shared`` and either ``-ffast-math`` or ``-funsafe-math-optimizations`` will no longer enable ``` https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
@@ -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 decision can be overridden andykaylor wrote: You may want to revise this to clarify that this only refers to the use of -shared and -ffast-math on the command-line used to link the program. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
@@ -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 -### %s -ffast-math -shared \ +// RUN:--gcc-toolchain="" \ andykaylor wrote: Do we have trouble with this test on systems where crtfastmath.o is not provided by the gcc toolchain? I don't think we provide our own version of this, do we? https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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 line flag makes it easier > for users to access rather than manually linking in a file located > who-knows-where in the toolchain (although I suspect anyone who cares hard > enough would rather just write the calls to set FTZ/DAZ than track it down > from the toolchain). I suppose there's also some portability value in supporting this gcc option. I guess I'd be OK with it. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] InstCombine: Enable SimplifyDemandedUseFPClass and remove flag (PR #81108)
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
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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 should not pass that to compile actions, and if they do, it should > result in a `-Wunused-command-line-argument` diagnostic, NOT a behavior > change. We're already parsing -nostartfiles and -nostdlib to determine the default setting. I don't see how looking at -shared makes it any worse. I would agree that this whole model is broken. If I use -ffast-math to create a bunch of object files (including the one containing main()) and then I link without that option, crtfastmath.o doesn't get linked, even though we used "denorm-fp-math"="preserveSign" on every function. I think we're in agreement that this needs to be fixed for x86-based targets. We just need to agree on how to do it. I think https://github.com/llvm/llvm-project/issues/57589 is a pretty egregious problem, and I'd like to see it fixed without delay, but given that it requires setting -ffast-math on your link line maybe it can wait for a proper fix. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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, which are relatively minor, afterwards. > > There is, without this change, no way to control whether or not > `crtfastmath.o` is linked independent of all of the other fast-math options. > The `-mdaz-ftz` option would at least add a flag to explicitly control the > parameter (for the people who care), and we can then have discussions about > different ways to effect setting DAZ/FTZ bits or what options imply > `-mdaz-ftz` in future PRs. That alone makes it a worthy addition IMHO; the > compatibility with gcc is another nice feature. You can always link crtfastmath.o directly, of course. Ultimately, I don't think the compiler should ever be adding the crtfastmath.o file. I would prefer to insert code directly into the entry function as @arsenm indicated the AMDGPU backend does for kernels. That would then be controlled by the -fdenormal-fp-math option or something more explicitly linked to the entry function. I don't want to add -mdaz-ftz because once we do we're kind of stuck with it. If you don't add it here, we'd continue the current behavior of linking with crtfastmath.o normally but we'd stop infecting shared libraries with it. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
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
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
@@ -2842,9 +2862,8 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
<< Args.MakeArgString("-ffp-model=" + FPModel)
<< Args.MakeArgString("-ffp-model=" + Val);
if (Val.equals("fast")) {
-optID = options::OPT_ffast_math;
FPModel = Val;
-FPContract = "fast";
+applyFastMath();
andykaylor wrote:
I just re-read you comment, and I think I see the confusion now. The previous
code was not easy to follow. We were changing the value of optID here, so when
we finished with this switch statement execution would continue on to the
switch statement below where the "whole pile of flags" was being set by the
OPT_ffast_math handler. Now I'm not changing the value of optID here and
instead calling the lambda to set the pile of flags. In a future revision I'd
like to add a parameter to the lambda to indicate that I want slightly less
aggressive fast math settings.
I started out with a change that chained all the OPT_ffast_math,
OPT_fno_fast_math, OPT_funsafe_math_optimizations, and
OPT_fno_unsafe_math_optimizations into a pair of nested lambdas with a
parameter for positive and negative versions, but that got way too convoluted
to handle all the variations needed to make it NFC. I think that pointed to
some things we're doing wrong, but I'll address those separately to keep the
history clean. This seemed like a manageable place to start.
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
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
@@ -2842,9 +2862,8 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
<< Args.MakeArgString("-ffp-model=" + FPModel)
<< Args.MakeArgString("-ffp-model=" + Val);
if (Val.equals("fast")) {
-optID = options::OPT_ffast_math;
FPModel = Val;
-FPContract = "fast";
+applyFastMath();
andykaylor wrote:
I'm pretty sure it is NFC. We have tests that verify this
([clang/test/Driver/fp-model.c](https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/fp-model.c)
and
[clang/test/Driver/fast-math.c](https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/fast-math.c)).
I'm only changing where the local variables are set. The FPContract value that
was being set here was also being set in the OPT_ffast_math handler. Now both
places call the lambda for everything they set.
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
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
@@ -3061,22 +3080,7 @@ static void RenderFloatingPointOptions(const ToolChain , const Driver , 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 not obvious from the diff, but the "fp-model" handler and the "ffast-math" handler are in different switch statements. 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
[clang] [NFC] Refactor fast-math handling for clang driver (PR #81173)
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 local option variable and
fell through to the -ffast-math handler.
This refactoring is intended to prepare the way for decoupling the
-ffp-model=fast settings from the -ffast-math settings and possibly introduce a
less aggressive fp-model.
>From 21299e729ad71cdb1c2a2737508ffc2ee6b21d0f Mon Sep 17 00:00:00 2001
From: Andy Kaylor
Date: Thu, 8 Feb 2024 10:44:22 -0800
Subject: [PATCH] [NFC] Refactor fast-math handling for clang driver
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
local option variable and fell through to the -ffast-math handler.
This refactoring is intended to prepare the way for decoupling the
-ffp-model=fast settings from the -ffast-math settings and possibly
introduce a less aggressive fp-model.
---
clang/lib/Driver/ToolChains/Clang.cpp | 40 +++
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 942ebbc4106078..4459d86e77d5d9 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2778,6 +2778,26 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
LangOptions::ComplexRangeKind Range = LangOptions::ComplexRangeKind::CX_None;
std::string ComplexRangeStr = "";
+ // Lambda to set fast-math options. This is also used by -ffp-model=fast
+ auto applyFastMath = [&]() {
+HonorINFs = false;
+HonorNaNs = false;
+MathErrno = false;
+AssociativeMath = true;
+ReciprocalMath = true;
+ApproxFunc = true;
+SignedZeros = false;
+TrappingMath = false;
+RoundingFPMath = false;
+FPExceptionBehavior = "";
+// If fast-math is set then set the fp-contract mode to fast.
+FPContract = "fast";
+// ffast-math enables limited range rules for complex multiplication and
+// division.
+Range = LangOptions::ComplexRangeKind::CX_Limited;
+SeenUnsafeMathModeOption = true;
+ };
+
if (const Arg *A = Args.getLastArg(options::OPT_flimited_precision_EQ)) {
CmdArgs.push_back("-mlimit-float-precision");
CmdArgs.push_back(A->getValue());
@@ -2842,9 +2862,8 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
<< Args.MakeArgString("-ffp-model=" + FPModel)
<< Args.MakeArgString("-ffp-model=" + Val);
if (Val.equals("fast")) {
-optID = options::OPT_ffast_math;
FPModel = Val;
-FPContract = "fast";
+applyFastMath();
} else if (Val.equals("precise")) {
optID = options::OPT_ffp_contract;
FPModel = Val;
@@ -3061,22 +3080,7 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
continue;
[[fallthrough]];
case options::OPT_ffast_math: {
- HonorINFs = false;
- HonorNaNs = false;
- MathErrno = false;
- AssociativeMath = true;
- ReciprocalMath = true;
- ApproxFunc = true;
- SignedZeros = false;
- TrappingMath = false;
- RoundingFPMath = false;
- FPExceptionBehavior = "";
- // If fast-math is set then set the fp-contract mode to fast.
- FPContract = "fast";
- SeenUnsafeMathModeOption = true;
- // ffast-math enables fortran rules for complex multiplication and
- // division.
- Range = LangOptions::ComplexRangeKind::CX_Limited;
+ applyFastMath();
break;
}
case options::OPT_fno_fast_math:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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/lib/Driver/ToolChains/Linux.cpp#L838). > This makes Clang for Linux X86 and X86-64 work the same as every other > OS/CPU combo. I don't see why the current denormal-fp-math setting behavior is a blocking issue for this change. Yes, compiling a shared library with ffast-math would lead to the "denormal-fp-math" attribute being set to a potentially misleading value, but that's already true for any file that is compiled with -ffast-math if the file containing the entry function isn't compiled with -ffast-math. I'd see fixing that as a separate issue. 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, which are relatively minor, afterwards. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)
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 anything about `-fdenormal-fp-math` due to > using `-ffast-math`. (as per the other paragraph in my last comment). Are youe suggesting that we should continue linking against crtfastmath.o when it is available and fast-math is enabled but we should set the "denormal-fp-math" attributes to "ieee" or "dynamic"? I want to make sure I'm understanding you correctly. Personally, I don't like linking with crtfastmath.o to get this behavior. I would prefer to insert code into whatever function(s), if any, we identify as a relevant entry point. That would require having the attribute set, at least for the entry function(s). Linking with crtfastmath.o depends on finding it, which I think makes it dependent on the GNU toolchain, and the static initializer is less visible to users debugging their program. For x86-based CPU targets, we really shouldn't be making assumptions about the FTZ/DAZ state for any function where we aren't setting it, but if it's useful for other targets, we shouldn't take that away. https://github.com/llvm/llvm-project/pull/80475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
