https://github.com/jcranmer-intel commented:
After banging my head on the desk trying to figure out why the tests were
giving such strange results, I realized the issue...
Could you please use `__builtin_complex` in the test to construct the complex
infinities instead of `__builtin_infinity()
@@ -5980,6 +5987,64 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
,
return Ret;
}
+static bool endsWithRoundingModeSuffix(StringRef FuncName) {
+ size_t Underscore = FuncName.find_last_of("_");
+ if (Underscore == StringRef::npos || Underscore < 2)
+return
@@ -5980,6 +5987,64 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
,
return Ret;
}
+static bool endsWithRoundingModeSuffix(StringRef FuncName) {
+ size_t Underscore = FuncName.find_last_of("_");
+ if (Underscore == StringRef::npos || Underscore < 2)
+return
@@ -1232,6 +1232,14 @@ class TargetInfo : public TransferrableTargetInfo,
return true;
}
+ /// Returns true, if an operations that depends on rounding mode can be
+ /// implemented without changing FP environment. In this case the rounding
+ /// mode is encoded in
https://github.com/jcranmer-intel commented:
Sorry for just thinking of this now, but we should also have tests for some of
the builtins like `__builtin_fma` or `__builtin_sqrt`.
https://github.com/llvm/llvm-project/pull/89617
___
cfe-commits mailing
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/89617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
I'm generally happy with the testing and semantics at this point.
https://github.com/llvm/llvm-project/pull/90877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -79,3 +79,16 @@ float V7 = []() -> float {
0x0.01p0F);
}();
// CHECK: @V7 = {{.*}} float 1.00e+00
+
+template struct L {
+ constexpr L() : value(V) {}
+ float value;
+};
+
+#pragma STDC FENV_ROUND FE_DOWNWARD
jcranmer-intel wrote:
The
jcranmer-intel wrote:
I've been doing some testing, and I do want to confirm my understanding of the
C standard here.
>From what I can tell, macro expansion (phase 4) happens before constants are
>parsed (phase 7). As a result, if you have code like this:
```c
#define CONSTANT 0.1f
```
the
https://github.com/jcranmer-intel approved this pull request.
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
https://github.com/jcranmer-intel requested changes to this pull request.
I haven't fully tested the changes yet, so right now I'm looking at the test to
figure out how much is supported. Nevertheless, I can already tell that this is
not complete support.
7.6.2p4 does clearly state that
jcranmer-intel wrote:
> The "etc." is eliding -fno-fast-math, -funsafe-math-optimizations, and
> -fno-unsafe-math-optimizations
Maybe "fast-math-ish flags" is a good summary of the lot?
https://github.com/llvm/llvm-project/pull/89477
___
cfe-commits
https://github.com/jcranmer-intel commented:
This may need some release notes adjustments as well; I already have a todo to
revisit the release notes around release time to make sure we get the summary
of the denormal handling flag changes right.
https://github.com/jcranmer-intel closed
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
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/5] Disable FTZ/DAZ when compiling shared libraries by
@@ -0,0 +1,160 @@
+// RUN: %clang_cc1 -S -triple x86_64-linux-gnu -emit-llvm %s -o - | \
+// RUN: FileCheck %s --implicit-check-not "call void @llvm.set.rounding"
--implicit-check-not "call i32 @llvm.get.rounding"
+
+float func_rz_ru(float w, float x, float y, float z) {
+
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/4] Disable FTZ/DAZ when compiling shared libraries by
https://github.com/jcranmer-intel edited
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
@@ -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 ,
-
jcranmer-intel wrote:
> 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
jcranmer-intel wrote:
Ping for review
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
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/3] Disable FTZ/DAZ when compiling shared libraries by
https://github.com/jcranmer-intel commented:
Other side notes:
fmin and frexp can signal exceptions if the input is an sNaN, which causes
[library.c]p3 to kick in. (That's the only time these operations can signal an
exception.)
https://github.com/llvm/llvm-project/pull/88978
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -373,6 +355,10 @@ C99 implementation status
Yes
+(2): Clang supports _Complex type specifiers
but
+does not support _Imaginary type specifiers. Support for
+_Imaginary is optional in C99 which is why Clang is fully
conforming.
jcranmer-intel
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
You're missing checks for type domain rules, so things like:
- converting between `float _Complex` and `double _Complex`
- common type of `float _Complex` and `double`
- result of `int` and `float _Complex`
- complex types not allowed in
https://github.com/jcranmer-intel approved this pull request.
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
@@ -310,6 +310,13 @@ class ComplexExprEmitter
CGF.getContext().getFloatTypeSemantics(ElementType);
const llvm::fltSemantics =
CGF.getContext().getFloatTypeSemantics(HigherElementType);
+// Check that LongDouble Size > Double Size.
+// This can be
@@ -310,6 +310,13 @@ class ComplexExprEmitter
CGF.getContext().getFloatTypeSemantics(ElementType);
const llvm::fltSemantics =
CGF.getContext().getFloatTypeSemantics(HigherElementType);
+// Check that LongDouble Size > Double Size.
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -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
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -982,13 +1024,18 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo ) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+
@@ -0,0 +1,143 @@
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - |
FileCheck %s --check-prefix=X86
+
+// Check that for 'F _Complex + int' (F = real floating-point type), we emit an
+// implicit cast from 'int' to 'F', but NOT to 'F _Complex' (i.e.
@@ -1114,8 +1114,6 @@ static bool handleIntegerToComplexFloatConversion(Sema
, ExprResult ,
if (IntTy->isIntegerType()) {
QualType fpTy = ComplexTy->castAs()->getElementType();
IntExpr = S.ImpCastExprToType(IntExpr.get(), fpTy, CK_IntegralToFloating);
-IntExpr =
@@ -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
@@ -982,13 +1022,18 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo ) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo );
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType
@@ -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
jcranmer-intel wrote:
> It matters more for AMDGPU, where we need to care because some instructions
> just don't respect denormals. We legalize some operations differently
> depending on the mode
But the shared library stuff isn't an issue for AMDGPU, right?
@@ -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
jcranmer-intel wrote:
I did a thorough investigation into how the
`denormal-fp-math=preserve-sign,preserve-sign` attribute affects the resulting
IR for all of the SPEC benchmarks (which actually do run into subnormals), and
the basic summary I found is that the only differences I found were
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From fc0507f013f556cc7c49a38f22d14578311f1f42 Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/3] Disable FTZ/DAZ when compiling shared libraries by
https://github.com/jcranmer-intel approved this pull request.
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
jcranmer-intel 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
jcranmer-intel 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
jcranmer-intel wrote:
> (Sidenote: "dynamic" isn't even
> [documented](https://clang.llvm.org/docs/UsersManual.html#cmdoption-fdenormal-fp-math)).
It's not a selectable enum of the Clang `-fdenormal-fp-math` flag, but it is
one for the LLVM function attribute `denormal-fp-math`.
jcranmer-intel wrote:
> I think there is a bit of a problematic interaction with
> getDenormalModeForType
> [here](https://github.com/llvm/llvm-project/blob/7a94acb2da5b20d12f13f3c5f4eb0f3f46e78e73/clang/lib/Driver/ToolChains/Linux.cpp#L838C8-L838C37).
> "-shared" is (should be) a flag used
https://github.com/jcranmer-intel created
https://github.com/llvm/llvm-project/pull/80475
This fixes https://github.com/llvm/llvm-project/issues/57589, and aligns Clang
with the behavior of current versions of gcc. There is a new option, -mdaz-ftz,
to control the linking of the file that sets
https://github.com/jcranmer-intel commented:
I haven't attempted to make my way through the sema changes yet, but some
comments already:
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
There's probably some useful discussion to be had about how aggressive
`-ffinite-math-only` at the clang level should be wrt lowering to `nnan`/`ninf`
in the IR.
It may be worth deferring the ReturnInst changes (but landing everything else)
until
jcranmer-intel wrote:
> [N2844](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2844.pdf), as
> linked by OP, references the removed language that you are looking for.
Doing some more spelunking, no released version of the TS ever had default
argument promotion. The change to the TS was
jcranmer-intel wrote:
> Should this only apply in C23 mode? Standard behavior until C23 is that
> `_Float16` promotes to `double`. What about C++?
I can't find any reference in older versions of C or TS 18661-3 that suggests
that `_Float16` is promoted to `double`. The wording of 6.5.2.2 used
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo ) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo ) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
@@ -28,4 +28,6 @@ OPTION(FPEvalMethod, LangOptions::FPEvalMethodKind, 2,
AllowApproxFunc)
OPTION(Float16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2,
FPEvalMethod)
OPTION(BFloat16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2,
Float16ExcessPrecision)
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo ) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
@@ -846,6 +859,31 @@ void Parser::HandlePragmaFEnvRound() {
Actions.ActOnPragmaFEnvRound(PragmaLoc, RM);
}
+void Parser::HandlePragmaCXLimitedRange() {
+ assert(Tok.is(tok::annot_pragma_cx_limited_range));
+ tok::OnOffSwitch OOS = static_cast(
+
https://github.com/jcranmer-intel commented:
I'm sure Aaron would appreciate me also saying that these changes would require
addition to the clang release notes.
https://github.com/llvm/llvm-project/pull/68820
___
cfe-commits mailing list
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/68820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2807,6 +2807,9 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
bool StrictFPModel = false;
StringRef Float16ExcessPrecision = "";
StringRef BFloat16ExcessPrecision = "";
+ StringRef CxLimitedRange = "NoCxLimiteRange";
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/66381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2313,14 +2313,20 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
GlobalDecl GD, unsigned BuiltinID,
FD->hasAttr() ? 0 : BuiltinID;
bool ErrnoOverriden = false;
- // True if math-errno is overriden via the
+ bool ErrnoOverrideValue = false;
Author: Joshua Cranmer
Date: 2023-09-13T08:57:10-07:00
New Revision: bf492371033378cec4c0443a3f87db0f818bbade
URL:
https://github.com/llvm/llvm-project/commit/bf492371033378cec4c0443a3f87db0f818bbade
DIFF:
Author: Joshua Cranmer
Date: 2023-03-13T14:20:24-04:00
New Revision: bcad161db3e69e27736c975ef5eeac60c96dcc97
URL:
https://github.com/llvm/llvm-project/commit/bcad161db3e69e27736c975ef5eeac60c96dcc97
DIFF:
71 matches
Mail list logo
