balazs-benics-sonarsource wrote:
Once we are settled on the implementation here, I'll split the `classof`
refactors from this PR and merge it before merging this one.
Should I measure the perf of this change?
https://github.com/llvm/llvm-project/pull/144327
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From a5ae39c1b8a5abc39f8948a724b354839e708e4b Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/5] [analyzer] Enforce not making overly compli
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From bc7dfc2b4f143c2caa1189db096bf9e4ea76f053 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH] [analyzer] Enforce not making overly complicate
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From 2c32b9f6dfa9a236cea5679b6613e567cd8dfc2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bal=C3=A1zs=20Benics?=
<108414871+balazs-benics-sonarsou...@users.noreply.github.com>
Date: Tue, 24 Jun 20
balazs-benics-sonarsource wrote:
Just rebased the PR to exclude the refactor change of `classof`. I'll schedule
a measurement now.
https://github.com/llvm/llvm-project/pull/144327
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/145500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145500
None
From 274a38f83b2c5c81968de865403cf114fc9550c0 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 13:42:42 +0200
Subject: [PATCH] [analyzer][docs] Mention perfetto for vis
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145501
None
From b67c2c5bfadc80121899690723ba938b398c4e65 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 13:14:31 +0200
Subject: [PATCH] [analyzer][NFC] Add xrefs to a test case
@@ -45,6 +45,7 @@ SYMBOL(SymbolCast, SymExpr)
ABSTRACT_SYMBOL(SymbolData, SymExpr)
SYMBOL(SymbolConjured, SymbolData)
+ SYMBOL(SymbolTooComplex, SymbolData)
balazs-benics-sonarsource wrote:
Renamed in b9edbc75bc87e4e263cb629f088ae9977a9cac03
https://githu
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145526
This should enable more powerful type metaprograms.
Split from #144327
From 2241ead76477da9eee6b8206a06abe841168b666 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 16:56:
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
balazs-benics-sonarsource wrote:
> > Should I measure the perf of this change?
>
> I think so, because the patch is substantially different. For example, the
> overly complex symbol tree is now preserved, even if it is apparently not
> traversed in its entirety any longer. That makes it not ob
@@ -671,17 +779,33 @@ class SymbolVisitor {
virtual bool VisitMemRegion(const MemRegion *) { return true; }
};
+// Returns a pointer to T if T is a SymbolData, otherwise SymExpr.
balazs-benics-sonarsource wrote:
Reworked the code, and dropped the `auto` typ
@@ -46,7 +50,7 @@ class SymbolRegionValue : public SymbolData {
friend class SymExprAllocator;
SymbolRegionValue(SymbolID sym, const TypedValueRegion *r)
- : SymbolData(SymbolRegionValueKind, sym), R(r) {
+ : SymbolData(ClassKind, sym), R(r) {
ba
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From a5ae39c1b8a5abc39f8948a724b354839e708e4b Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/3] [analyzer] Enforce not making overly compli
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/145501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
I wanted to look at recently of the history of this test file. I managed to dig
it up, but since the git blame didn't tell me much I think it's worth to spell
out these refs explicitly.
https://github.com/llvm/llvm-project/pull/145501
__
@@ -317,21 +317,21 @@ class SValBuilder {
return nonloc::LocAsInteger(BasicVals.getPersistentSValWithData(loc,
bits));
}
- nonloc::SymbolVal makeNonLoc(const SymExpr *lhs, BinaryOperator::Opcode op,
- APSIntPtr rhs, QualType type);
+ Defi
balazs-benics-sonarsource wrote:
> > I was thinking about possible ways to unblock this change.
> > If the additional code complexity needs justification, by measuring the
> > average impact (to ensure no regression happens in the common cases), and
> > by repeating the measurement of the handf
balazs-benics-sonarsource wrote:
I was thinking about possible ways to unblock this change.
If the additional code complexity needs justification, by measuring the average
impact (to ensure no regression happens in the common cases), and by repeating
the measurement of the handful of edge-case
balazs-benics-sonarsource wrote:
> Unfortunately I'm not convinced that this is the right direction for
> improving the analyzer runtime.
>
> On the "risks" side I think that adding the corner case that "this may also
> return `UnknownVal` in rare situations" into many functions complicates th
@@ -63,6 +64,42 @@ void testGlobalNoThrowPlacementExprNewBeforeOverload() {
int *p = new(std::nothrow) int;
} // leak-warning{{Potential leak of memory pointed to by 'p'}}
+//- Standard pointer placement operators
+void testGlobalPointerPlacementNew() {
+ int i;
+ void
@@ -67,7 +67,7 @@ void ExprEngine::VisitBinaryOperator(const BinaryOperator* B,
if (RightV.isUnknown()) {
unsigned Count = currBldrCtx->blockCount();
RightV = svalBuilder.conjureSymbolVal(nullptr, getCFGElementRef(),
LCtx,
-
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/144327
Out of the worst 500 entry points, 45 were improved by at least 10%. Out of
these 45, 5 were improved by more than 50%. Out of these 45, 2 were improved by
more than 80%.
For example, for the
balazs-benics-sonarsource wrote:
> @steakhal Thanks for the updates, I'm completely satisfied with them.
>
> I don't see any connection between this commit and the buildbot failures 🤔
> ... they are probably unrelated.
About 90% of the time they are unrelated. I don't usually put a confirmatio
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140924
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
> In the tests I felt that it'd be a bit hard to decipher the meaning of the
> block identifiers like `B1` etc. -- but when I re-read the file I noticed
> that you included the very nice helper function `dumpCFGAndEgraph` (IIUC) for
> those who will need to deb
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/7] [analyzer] Introduce the check::BlockEntran
@@ -166,6 +179,23 @@ class CheckerDocumentation
/// check::Bind
void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &) const {}
+ /// Called after a CFG edge is taken within a function.
+ ///
+ /// This callback can be used to obtain information about poten
@@ -548,6 +564,8 @@ class CheckerProgramPointTag : public SimpleProgramPointTag
{
template
class Checker : public CHECK1, public CHECKs..., public CheckerBase {
public:
+ using BlockEntrance = clang::BlockEntrance;
balazs-benics-sonarsource wrote:
> Note th
@@ -548,6 +564,8 @@ class CheckerProgramPointTag : public SimpleProgramPointTag
{
template
class Checker : public CHECK1, public CHECKs..., public CheckerBase {
public:
+ using BlockEntrance = clang::BlockEntrance;
balazs-benics-sonarsource wrote:
Yes, the
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/4] [analyzer] Introduce the check::BlockEntran
@@ -166,6 +179,23 @@ class CheckerDocumentation
/// check::Bind
void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &) const {}
+ /// Called after a CFG edge is taken within a function.
+ ///
+ /// This callback can be used to obtain information about poten
balazs-benics-sonarsource wrote:
I know it didn't actually pass a week for a ping, but let me know if its on the
horizon.
https://github.com/llvm/llvm-project/pull/140924
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
balazs-benics-sonarsource wrote:
> What is the relationship of this new callback with the `BranchCondition`
> callback which is evaluated in `ProcessBranch` where the checker splits the
> execution path into multiple branches? It would be nice if you could document
> the difference between the
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/3] [analyzer] Introduce the check::BlockEntran
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140924
Tranersing the CFG blocks of a function is a fundamental operation. Many C++
constructs can create splits in the control-flow, such as `if`, `for`, and
similar control structures or ternary ex
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140861
This helps to gain contextual information about how we entered a CFG block.
The `noexprcrash.c` test probably changed due to the fact that now
BlockEntrance ProgramPoint Profile also hashes th
balazs-benics-sonarsource wrote:
/cc @necto
https://github.com/llvm/llvm-project/pull/140861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
I've updated the PR. I noticed some mistakes in the original submission.
Could you please have a look?
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140035
From 3ef0391fdc58503f3414ac64e42370b0a6d4bddf Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 11:17:24 +0200
Subject: [PATCH] [analyzer][NFC] Move PrettyStackTraceLocationCo
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140035
From 42343959f623153dc9421e3bb569b2f0527ec119 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 11:17:24 +0200
Subject: [PATCH 1/2] [analyzer][NFC] Move PrettyStackTraceLocati
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
/CC @pdschbrt
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140035
This change helps with ensuring that the abstract machine call stack is only
dumped exactly once no matter what checker callback we have the crash in.
Note that some checker callbacks happen o
balazs-benics-sonarsource wrote:
Thanks for the fix, I'll proceed with the backport if you still believe it's
worthy. @NagyDonat
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
https://github.com/balazs-benics-sonarsource approved this pull request.
Thank you!
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
@Xazax-hun WDYT of the proposed alternative flag name?
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
https://github.com/balazs-benics-sonarsource commented:
Looks good. There were two points unaddressed:
- Finding a name for the flag without the `legacy-` prefix
- Find out if we can ever have multiple root nodes in an exploded graph.
https://github.com/llvm/llvm-project/pull/136720
_
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
I can see your points. I think they indeed moves the needle slightly for having
this (or a similar) flag but barely.
I'd need to think about a better flag name, but right now I'm too busy for that.
https://github.com/llvm/llvm-project/pull/136720
___
balazs-benics-sonarsource wrote:
> 🤔 The version with the commit under review is surprisingly fast and I don't
> exactly know why. My most plausible theory is that
> [bb27d5e](https://github.com/llvm/llvm-project/commit/bb27d5e5c6b194a1440b8ac4e5ace68d0ee2a849)
> ("Don't assume third iteration
balazs-benics-sonarsource wrote:
Do you have data about the analysis times per file, and per analysis entry
point?
Compared against the current llvm main, and also if this workaround would
restore the original running times before
https://github.com/llvm/llvm-project/commit/bb27d5e5c6b194a1440
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -81,10 +81,6 @@ class FunctionSummariesTy {
I->second.MayInline = 0;
}
- void markReachedMaxBlockCount(const Decl *D) {
-markShouldNotInline(D);
- }
balazs-benics-sonarsource wrote:
I'd not mind keeping this if there was more thing to do once a
@@ -2856,8 +2873,29 @@ void ExprEngine::processBranch(
// conflicts with the widen-loop analysis option (which is off by
// default). If we intend to support and stabilize the loop widening,
// we must ensure that it 'plays nicely' with this logic.
- if (
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
balazs-benics-sonarsource wrote:
One other note. We should backport this fix to clang-20 once it lands to main.
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource requested changes to this pull
request.
Thank you for investigating this. At Sonar, we have not yet started the upgrade
to clang-20. I suppose, you already did then, thus found this regression on
trunk.
Maybe we should also reflect of the quality c
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
balazs-benics-sonarsource wrote:
I'd prefer option 2, because why else would we have a default compiler if that
wasn't used in some workflows.
A warning could never hurt. I'm also flexible on the subject.
https://github.com/llvm/llvm-project/pull/131932
_
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/133236
These metrics would turn out to be useful for verifying an upgrade of Z3.
From 5fe04bcbb3eaf5682037ada6ab64fd7e021f787e Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 27 Mar 2025 12:1
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/131932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
Looks good as it is right now. Thanks for putting the effort into this.
I've invited the rest of the folks probably interested in this to get a second
opinion.
https://github.com/llvm/llvm-project/pull/131932
___
cfe-c
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/131932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource approved this pull request.
Thanks for the context. It looks good to me now.
@haoNoQ, maybe you know some Perl, could you have a second opinion?
Otherwise, let's merge this in a week.
https://github.com/llvm/llvm-project/pull/131932
_
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/129224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
Confirmed crash, https://compiler-explorer.com/z/fzoqP36xq
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
balazs-benics-sonarsource wrote:
> Hello @balazs-benics-sonarsource
>
> The following starts crashing with this patch: `clang --analyze bbi-104578.c`
> It crashes with
Thank you for the heads up @mikaelholmen. I'll switch to it ASAP. I'd expect
the fix later today.
https://github.com/llvm/ll
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
> Anyway, let's just merge this as it is now.
>
> The code is basically OK, I still don't have the brainpower to hold all the
> details in my mind (kudos for the fact that _you_ managed to put this
> together) and if I'll catch some divine inspiration in the fu
@@ -179,8 +181,41 @@ bool CoreEngine::ExecuteWorkList(const LocationContext *L,
unsigned MaxSteps,
return WList->hasWork();
}
-void CoreEngine::dispatchWorkItem(ExplodedNode* Pred, ProgramPoint Loc,
- const WorkListUnit& WU) {
+static std::s
@@ -359,7 +326,80 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefhttps://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
@@ -359,7 +326,80 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefhttps://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
balazs-benics-sonarsource wrote:
> As I thought a bit more about the reorganization that I suggested, I realized
> that it can be summarized as **we should synchronize adding the default
> `Unknown` binding and calling `escapeValue`** -- because they correspond to
> the two end-points of the s
balazs-benics-sonarsource wrote:
Thanks for your long review. I'm sorry if the poor code quality hindered the
comprehension.
My goal was to minimize the diff for easier review, but I admit that I should
have attached some considerations as to why I implemented it this way, and also
how differe
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -483,6 +483,14 @@ ANALYZER_OPTION(
"behavior, set the option to 0.",
5)
+ANALYZER_OPTION(
+unsigned, RegionStoreMaxBindingFanOut, "region-store-max-binding-fanout",
+"This option limits how many sub-bindings a single binding operation can "
+"scatter int
@@ -2782,6 +2865,8 @@ RegionBindingsRef
RegionStoreManager::bindStruct(RegionBindingsConstRef B,
if (VI == VE)
break;
+ if (NewB.hasExhaustedBindingLimit())
+return NewB.escapeValues(VI, VE);
balazs-benics-sonarsource wrote:
I've r
@@ -176,31 +177,59 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefpush_back(V);
+return *this;
+ }
+ RegionBindingsRef escapeValues(nonloc::CompoundVal::iterator Begin,
+ nonloc::CompoundVal::iterator End) const {
+for (SVal V :
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/127602
From f5cd6b22fb83c0bfb584717cde6899cd65fc1274 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Wed, 5 Feb 2025 17:13:34 +0100
Subject: [PATCH 1/7] [analyzer] Limit Store by region-store-bindi
balazs-benics-sonarsource wrote:
@Flandini @necto
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/127602
In our test pool, the max entry point RT was improved by this change: 1'181
seconds (~19.7 minutes) -> 94 seconds (1.6 minutes)
BTW, the 1.6 minutes is still really bad. But a few orders of ma
balazs-benics-sonarsource wrote:
LGTM, I'll merge this PR once the premerge checks are green. Should be ready in
a couple of hours. Thanks for the PR again!
https://github.com/llvm/llvm-project/pull/125508
___
cfe-commits mailing list
cfe-commits@list
https://github.com/balazs-benics-sonarsource approved this pull request.
I had a look at the PR, and it looks awesome.
Could you please update the attached speedscope image?
It looks like it's out of sync with the implementation, for example if you look
at the "Loc PostStmt { ... stuff here ...}
https://github.com/balazs-benics-sonarsource deleted
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 104 matches
Mail list logo
