https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/139492
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/139492
>From 95522dc44fa7c807cf0278e0ce0a62bc0761ed04 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Fri, 9 May 2025 23:29:08 +0700
Subject: [PATCH 1/2] [NFC] Optimize File kind determination
There are checks in c
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/139492
There are checks in clang codebase that determine the type of source file,
associated with a given location - specifically, if it is an ordonary file or
comes from sources like command-line options or a built-
spavloff wrote:
Thre is a separate fix for lowering in Selection DAG:
https://github.com/llvm/llvm-project/pull/138553,
https://github.com/llvm/llvm-project/pull/135658
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
Juan Manuel Martinez =?utf-8?q?Caama=C3=B1o?=
Message-ID:
In-Reply-To:
https://github.com/spavloff approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/137306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
spavloff wrote:
> Tests for FP operand bundles on a non-intrinsic function would be helpful.
This patch's operand bundles are designed specifically for use with intrinsic
functions, similar to constrained intrinsics. Using operand bundles with
user-supplied function would require refining sema
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/135658
>From 287340535219cd5bc31de3a27cde1b279db0eb09 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 14 Apr 2025 12:51:43 +0700
Subject: [PATCH 1/6] Minimal support of floating-point operand bundles
This is a
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/135658
>From 287340535219cd5bc31de3a27cde1b279db0eb09 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 14 Apr 2025 12:51:43 +0700
Subject: [PATCH 1/2] Minimal support of floating-point operand bundles
This is a
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu %s
+
+bool a;
+constexpr const unsigned char c[] = { 5 };
+constexpr const unsigned char d[1] = { 0 };
+auto b = (a ? d : c);
+
+constexpr const unsigned char c1[][1] = {{ 5 }};
+constexpr const unsigned char d1[1][1] =
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/131649
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spavloff wrote:
Fixed in https://github.com/llvm/llvm-project/pull/132559.
https://github.com/llvm/llvm-project/pull/131649
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/132559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -14171,6 +14171,15 @@ static QualType getCommonSugarTypeNode(ASTContext
&Ctx, const Type *X,
static auto unwrapSugar(SplitQualType &T, Qualifiers &QTotal) {
SmallVector R;
while (true) {
+if (const auto *ATy = dyn_cast(T.Ty)) {
+ // C++ 9.3.3.4p3: Any type of t
@@ -14171,6 +14171,15 @@ static QualType getCommonSugarTypeNode(ASTContext
&Ctx, const Type *X,
static auto unwrapSugar(SplitQualType &T, Qualifiers &QTotal) {
SmallVector R;
while (true) {
+if (const auto *ATy = dyn_cast(T.Ty)) {
+ // C++ 9.3.3.4p3: Any type of t
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/131649
>From cdf9f1a5b960d2561a7c4415313b397578de0f8b Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 17 Mar 2025 21:33:24 +0700
Subject: [PATCH 1/2] [clang] Fix array types comparison in
getCommonSugaredType
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/131366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spavloff wrote:
MR https://github.com/llvm/llvm-project/pull/131649 implements an alternative
fix to the problem.
https://github.com/llvm/llvm-project/pull/131366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/131649
Const-qualification of an array caused by constexpr specifier can produce
QualType, where the const qualifier is set both as fast qualifier and as a
qualifier of the array element type. It can result in a comp
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/131366
Const-qualification of an array caused by constexpr specifier can produce
QualType, where the const qualifier is set both as fast qualifier and as a
qualifier of the array element type. It can result in a comp
spavloff wrote:
Thank you for the clarification. Let's keep the meaning of this attribute as it
currently stands.
The explanations raises some concern, though. OK, strictfp at call sites keeps
previous property of the call even if the basic block is detached. If a block
is taken from a stric
spavloff wrote:
> > If strict floating-point semantics are required at this call site, they are
> > are required on every relevant call in this function. It means strictfp is
> > a function attribute. Does anything prevents us from removal strictfp from
> > all call sites?
>
> I think that tak
spavloff wrote:
> My understanding of the attribute is that it only indicates that strict
> floating-point semantics are (potentially?) required at the call site.
If strict floating-point semantics are required at this call site, they are are
required on every relevant call in this function.
spavloff wrote:
Thank you for your retrospective view on `strictfp`. I didn't realize how much
it is related to inlining. This use case should be carefully analyzed to refine
meaning of the attribute.
> Clearly intrinisics don't get inlined by the Inliner. But what if an
> intrinsic gets lowe
@@ -66,6 +66,12 @@ bool IntrinsicInst::mayLowerToFunctionCall(Intrinsic::ID
IID) {
}
}
+bool IntrinsicInst::canAccessFPEnvironment(LLVMContext &C, Intrinsic::ID IID) {
+ AttributeList Attrs = Intrinsic::getAttributes(C, IID);
+ MemoryEffects ME = Attrs.getMemoryEffects();
@@ -66,6 +66,17 @@ bool IntrinsicInst::mayLowerToFunctionCall(Intrinsic::ID
IID) {
}
}
+bool IntrinsicInst::canAccessFPEnvironment(Intrinsic::ID IID) {
+ switch (IID) {
+#define DAG_INSTRUCTION(NAME, NARG, ROUND_MODE, INTRINSIC, DAGN)
\
+case Intrinsic::INTR
spavloff wrote:
This patch was obtained from the commit "Don't set strictfp on irrelevant
calls" from #109798.
https://github.com/llvm/llvm-project/pull/122735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -86,6 +86,43 @@ IRBuilderBase::createCallHelper(Function *Callee,
ArrayRef Ops,
return CI;
}
+CallInst *IRBuilderBase::CreateCall(FunctionType *FTy, Value *Callee,
+ArrayRef Args,
+ArrayRef OpBundles
@@ -273,29 +306,6 @@ void InstrProfCallsite::setCallee(Value *Callee) {
setArgOperand(4, Callee);
}
-std::optional ConstrainedFPIntrinsic::getRoundingMode() const {
- unsigned NumOperands = arg_size();
- Metadata *MD = nullptr;
- auto *MAV = dyn_cast(getArgOperand(NumOper
spavloff wrote:
### Merge activity
* **Dec 2, 1:35 AM EST**: The merge label 'FP Bundles' was detected. This PR
will be added to the [Graphite merge
queue](https://app.graphite.dev/merges?org=llvm&repo=llvm-project) once it
meets the requirements.
https://github.com/llvm/llvm-project/pull/1
spavloff wrote:
PR https://github.com/llvm/llvm-project/pull/118253 demonstrates changes
required to upgrade an intrinsic (`trunc` in this case) to using FP operand
bundles.
https://github.com/llvm/llvm-project/pull/109798
___
cfe-commits mailing li
spavloff wrote:
### Merge activity
* **Dec 2, 12:55 AM EST**: The merge label 'FP Bundles' was detected. This PR
will be added to the [Graphite merge
queue](https://app.graphite.dev/merges?org=llvm&repo=llvm-project) once it
meets the requirements.
https://github.com/llvm/llvm-project/pull/
spavloff wrote:
`FPOptions` were added to `CompoundStmt` to help code generation for `#pragma
STDC FENV_ROUND`. If dynamic rounding is used, compiler should emit a code that
switch it. There is no AST nodes for pragmas, so there is no a good place to
emit such code. To solve this problem Compo
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -ffast-math -ffp-contract=fast -emit-llvm -o - %s |
FileCheck %s
+// RUN: %clang_cc1 -ffast-math -ffp-contract=fast -emit-llvm -O2 -o - %s |
FileCheck %s
spavloff wrote:
Yes, this fact is reflected in #84648. Actually the pro
@@ -1684,6 +1684,15 @@ class CompoundStmt final
return hasStoredFPFeatures() ? getStoredFPFeatures() : FPOptionsOverride();
}
+ /// Get FPOptions inside this statement. They may differ from the outer
+ /// options due to pragmas.
+ /// \param CurFPOptions FPOptions ou
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/111654
>From a47216330a0e14025ba2c29a884d6a96d472dd73 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Wed, 9 Oct 2024 12:55:22 +0700
Subject: [PATCH 1/2] [clang] Set FPOptions at the beginning of CompoundStmt
Compo
spavloff wrote:
Ping.
https://github.com/llvm/llvm-project/pull/111654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spavloff wrote:
> > Right, we would need to introduce new llvm.fadd etc. to carry bundles. If
> > there are no bundles these could fold back to the regular instruction
>
> Good. The new intrinsics will be unknown to the optimization passes and thus
> be "safe by default".
Optimization passes
spavloff wrote:
I made an alternative PR, which does not need changes in ConditionalOperator:
https://github.com/llvm/llvm-project/pull/111654.
https://github.com/llvm/llvm-project/pull/105912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/111654
CompoundStmt has FPOptions, that should be set for IRBuilder when generating
code if that statement.
It must fix the issue #84648.
>From a7f150c90c301cdd5f55cf6eb44f4e8cf77625f1 Mon Sep 17 00:00:00 2001
From:
spavloff wrote:
> Any instruction that returns a floating-point value can have fast-math flags
> attached to it, and because we need to check the fast-math flags on input
> operands, the select instruction generated by the conditional operator needs
> the flags set when fast-math is enabled. T
spavloff wrote:
I don't think think setting FPOptions in `ConditionalOperator` is a good idea.
This operator does not represent any floating-point operation so setting FP
properties on it does not look reasonable.
Instead, I would like to propose you using FPOptions from CompoundStmt, you
cou
spavloff wrote:
> This sounds like a rejection of safe-by-default.
What do you mean by "safe-by-default"? Implementation must be correct, and
produce the code that executes in accordance to standards and documentation.
Any deviation from them is an error and should be fixed. Does it mean that
@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef
Name, CallBase *CI) {
CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator());
}
+static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F,
+
@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef
Name, CallBase *CI) {
CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator());
}
+static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F,
+
@@ -2994,6 +2994,29 @@ A "convergencectrl" operand bundle is only valid on a
``convergent`` operation.
When present, the operand bundle must contain exactly one value of token type.
See the :doc:`ConvergentOperations` document for details.
+.. _ob_fpe:
+
+Floating-point Envir
spavloff wrote:
> I don't think attaching these operand bundles to the existing set of
> intrinsics is what we want to do. I'd prefer to deprecate the existing
> intrinsics and define some new scheme that uses these bundles on intrinsics
> that may be used in other ways.
>
> One of the origin
@@ -47,6 +47,15 @@ enum class RoundingMode : int8_t {
Invalid = -1///< Denotes invalid value.
};
+inline bool isValidRoundingMode(int X) {
+ return X >= 0 && X <= static_cast(RoundingMode::Dynamic);
spavloff wrote:
This is bad function name. Actually s
@@ -357,6 +357,9 @@ class IRBuilderBase {
void setConstrainedFPCallAttr(CallBase *I) {
I->addFnAttr(Attribute::StrictFP);
+MemoryEffects ME = MemoryEffects::inaccessibleMemOnly();
spavloff wrote:
If a constrained intrinsic like `experimental_constra
@@ -43,6 +43,15 @@ enum ExceptionBehavior : uint8_t {
}
+inline bool isValidExceptionBehavior(unsigned X) {
spavloff wrote:
I think this is historically, because the functionality was implemented by
different people. We have "FPE.h" and "FloatingPointMode.h
@@ -2994,6 +2994,29 @@ A "convergencectrl" operand bundle is only valid on a
``convergent`` operation.
When present, the operand bundle must contain exactly one value of token type.
See the :doc:`ConvergentOperations` document for details.
+.. _ob_fpe:
+
+Floating-point Envir
@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef
Name, CallBase *CI) {
CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator());
}
+static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F,
+
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/109798
Currently floating-point operations in general form (beyond the default mode)
are always represented by calls to constrained intrinsics. In addition to the
side effect, they carry additional information in the
spavloff wrote:
The discussion for the proposed mechanism is open here:
https://discourse.llvm.org/t/rfc-calling-functions-if-pragma-fenv-round-is-present/79372
> > This change introduces macro ROUNDING_MODE, which is a string dependent on
> > the constant rounding mode
>
> It expands to an id
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/92699
>From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Sun, 19 May 2024 18:43:08 +0700
Subject: [PATCH 1/4] [clang] Macro for constant rounding mode
MIME-Version: 1.0
Co
spavloff wrote:
Thanks! I will commit it in a couple of day, if no additional feedback is
provided.
https://github.com/llvm/llvm-project/pull/92699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -965,6 +965,16 @@ void Preprocessor::Lex(Token &Result) {
LastTokenWasAt = Result.is(tok::at);
--LexLevel;
+ if (Result.is(tok::l_brace)) {
+CurlyBraceLevel++;
+ } else if (Result.is(tok::r_brace)) {
+if (!RoundingPragmas.empty() &&
spavloff w
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/92699
>From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Sun, 19 May 2024 18:43:08 +0700
Subject: [PATCH 1/3] [clang] Macro for constant rounding mode
MIME-Version: 1.0
Co
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -emit-llvm -triple i386-linux -Wno-unknown-pragmas %s -o -
| FileCheck %s
spavloff wrote:
Parsing pragma FENV_ROUND has been moved to the preprocessor.
https://github.com/llvm/llvm-project/pull/92699
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/92699
>From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Sun, 19 May 2024 18:43:08 +0700
Subject: [PATCH 1/2] [clang] Macro for constant rounding mode
MIME-Version: 1.0
Co
https://github.com/spavloff ready_for_review
https://github.com/llvm/llvm-project/pull/92699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -emit-llvm -triple i386-linux -Wno-unknown-pragmas %s -o -
| FileCheck %s
spavloff wrote:
No, this macro is managed by the code in Sema, because pragma FENV_ROUND is
processed there. If only `-E` is specified, __ROUNDING_MOD
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/92699
>From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Sun, 19 May 2024 18:43:08 +0700
Subject: [PATCH] [clang] Macro for constant rounding mode
MIME-Version: 1.0
Conten
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/92699
The forthcoming C standard defines pragma FENV_ROUND to support constant
rounding mode. It also requires some functions to be evaluated with such mode,
N3096 7.6.2p4 states:
Within the scope of an FENV_ROU
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/90877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spavloff wrote:
> The changes should come with a release note so that users know about the
> behavioral change, but otherwise LGTM.
Pragma FENV_ROUND is still officially unsupported, compiler issues a warning
about this. It is https://github.com/llvm/llvm-project/pull/89617 that makes
FENV_RO
spavloff wrote:
Are there any other comments? Can this PR be considered as approved?
https://github.com/llvm/llvm-project/pull/90877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/92146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -emit-pch -DHEADER -x c++-header %s -o %t.pch
+// RUN: %clang_cc1 -emit-llvm -include-pch %t.pch %s -o /dev/null
+
+#ifdef HEADER
+__attribute__((optnone)) void foo() {}
+#endif
spavloff wrote:
It is to avoid redefinition error
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/92146
>From 4f6f0acb47d21b25e4e86733a81d609f4de7dc3c Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Tue, 14 May 2024 23:11:21 +0700
Subject: [PATCH 1/2] [clang] Store FPOptions earlier when parsing function
After
spavloff wrote:
PR https://github.com/llvm/llvm-project/pull/92146 does not solve the problem
of serialization mentioned above, but it is simple and quick solution for the
reported crash.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commit
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/92146
After https://github.com/llvm/llvm-project/pull/85605 ([clang] Set correct
FPOptions if attribute 'optnone' presents) the current FP options in Sema are
saved during parsing function because Sema can modify the
spavloff wrote:
Hi @SLTozer,
Thank you for the report. There is an issue somewhere around the code that
reads/wtites records FP_PRAGMA_OPTIONS and/or FLOAT_CONTROL_PRAGMA_OPTIONS,
which sometimes manifest itseld in broken synchronization of FP options. I will
prepare fix soon.
https://github
spavloff wrote:
> 7.6.2p4 does clearly state that floating constants need to be evaluated
> according to the standard rounding mode, so that the constant 0.1 evaluates
> to a different value in FE_DOWNWARD versus FE_UPWARD.
Treatment of floating-point constants is fixed in
https://github.com/
https://github.com/spavloff 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/spavloff updated
https://github.com/llvm/llvm-project/pull/89617
>From ec8838685fb7af618445c3ff1bae953778996c37 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 14 Apr 2022 18:00:14 +0700
Subject: [PATCH 1/3] Implementation of '#pragma STDC FENV_ROUND'
This pragma is i
@@ -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
spavloff wrote:
Explicit instantiati
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 01/10] [clang] Use constant rounding mode for floating
literals
C
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/91061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -968,10 +968,7 @@ class FPOptionsOverride {
setAllowFPContractAcrossStatement();
}
- void setDisallowOptimizations() {
-setFPPreciseEnabled(true);
-setDisallowFPContract();
- }
+ void setDisallowOptimizations() { setFPPreciseEnabled(true); }
-
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 1/8] [clang] Use constant rounding mode for floating literals
Conv
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/91061
>From 32c0ec8a03b0c669dc595894730dd6f8a7933dea Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Sat, 4 May 2024 12:26:22 +0700
Subject: [PATCH 1/2] [clang] Enable FPContract with optnone
Previously treatment o
spavloff wrote:
Hi @wjristow,
Thank you for your detailed analysis. Indeed, FPContract looks more like
mandatory option rather than optional optimization. I prepared PR:
https://github.com/llvm/llvm-project/pull/91061, which fixes this issue.
https://github.com/llvm/llvm-project/pull/85605
__
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/91061
Previously treatment of the attribute `optnone` was modified in
https://github.com/llvm/llvm-project/pull/85605 ([clang] Set correct FPOptions
if attribute 'optnone' presents). As a side effect FPContract was d
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 1/7] [clang] Use constant rounding mode for floating literals
Conv
@@ -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
spavloff wrote:
> Does the FENV_ROUN
@@ -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
spavloff wrote:
In this snippet `Val
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 1/5] [clang] Use constant rounding mode for floating literals
Conv
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 1/4] [clang] Use constant rounding mode for floating literals
Conv
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/90877
>From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 2 May 2024 22:28:05 +0700
Subject: [PATCH 1/2] [clang] Use constant rounding mode for floating literals
Conv
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/90877
Conversion of floating-point literal to binary representation must be made
using constant rounding mode, which can be changed using pragma FENV_ROUND. For
example, the literal "0.1F" should be representes by ei
spavloff wrote:
Hi @dyung.
The observed difference is due to the FP contraction turned off if optnone is
specified. In O0 this optimization is still applied. As a result, the function
with optnone contains separate fadd and fmul, while without this attribute the
function contains combined ope
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/89617
>From 0fc5c57264ecf51f8b9fe8303520a51cb1fee40e Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 14 Apr 2022 18:00:14 +0700
Subject: [PATCH 1/2] Implementation of '#pragma STDC FENV_ROUND'
This pragma is i
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/89617
>From 0fc5c57264ecf51f8b9fe8303520a51cb1fee40e Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 14 Apr 2022 18:00:14 +0700
Subject: [PATCH] Implementation of '#pragma STDC FENV_ROUND'
This pragma is intro
spavloff wrote:
Thanks!
> Is there any existing bookkeeping we no longer need to do if we're going to
> have this RAII object in scope during function parsing?
It seems handling fast-math is the only case that prevented using this RAII
object.
https://github.com/llvm/llvm-project/pull/85605
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/89617
>From fc7aab600c25b39b2df039c0cbcf517719736311 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Thu, 14 Apr 2022 18:00:14 +0700
Subject: [PATCH] Implementation of '#pragma STDC FENV_ROUND'
This pragma is intro
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/89617
This pragma is introduced by forthcoming C2x standard and can be used to set
particular rounding mode without need to call 'fesetmode' or accessing control
mode registers directly. Previously this pragma was im
spavloff wrote:
A little about the significance of this fix. To implement pragma FENV_ROUND, we
need to apply the FP options stored in the instance of CompoundStmt to the
builder object, so that it uses the specified rounding mode. It can be done
using the class CGFPOptionsRAII. However in thi
spavloff wrote:
Ping.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 07e171e0566ab584299a57c210106bb8220c6261 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH 1/4] [clang] Set correct FPOptions if attribute 'optnone'
present
1 - 100 of 434 matches
Mail list logo
