@@ -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
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 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 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 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
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] =
401 - 426 of 426 matches
Mail list logo
