@@ -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
@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef
Name, CallBase *CI) {
CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator());
}
+static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F,
+
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
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:
### 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:
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
@@ -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:
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
@@ -86,6 +86,43 @@ IRBuilderBase::createCallHelper(Function *Callee,
ArrayRef Ops,
return CI;
}
+CallInst *IRBuilderBase::CreateCall(FunctionType *FTy, Value *Callee,
+ArrayRef Args,
+ArrayRef OpBundles
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:
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
@@ -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
@@ -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();
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
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
@@ -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 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
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
@@ -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 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
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
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 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
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
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:
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
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/2] Minimal support of floating-point operand bundles
This is a
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-
401 - 434 of 434 matches
Mail list logo
