@@ -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:
Backporting this updated version to clang-19 was not easy but it allowed to
verify this PR.
Unfortunately, there is a bug in this updated version, that I'll explain.
Even after I fixed this bug, however, on a sample it ran about 19.36% slower
under analyzing has
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
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
@@ -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:
> [...] This different sort of limitation still guarantees that we cannot build
> overly complex symbols, but its implementation is significantly shorter (just
> three early return statements for unary operator, binary operator and cast
> evaluation).
>
> 💡 In
balazs-benics-sonarsource wrote:
> > So, I think if we go with the evalbinop approach, then it should work as
> > efficiently as my original proposal, while sacreficing the special cases
> > that fold away the binop. I'm fine with either of the approaches.
> > I scheduled a measurement for the
balazs-benics-sonarsource wrote:
> However, I think I see another, less complex approach for "fixing" the method
> `acquire`: instead of creating the `Dummy` symbol and calculating its
> complexity early, just modify the original state of the method (i.e. the
> parent revision of
> [8c29bbc](
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 1/2] [analyzer] Enforce not making overly compli
balazs-benics-sonarsource wrote:
> The parts of the flamegraph that you highlight are presumably coming from the
> _other_ operand whose simplification is skipped due to the presence of the
> `UnknownVal`.
Yes, this is my theory, but this still wouldn't explain why I didn't see these
simplify
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 1/5] [analyzer] Enforce not making overly compli
balazs-benics-sonarsource wrote:
> > > So, I think if we go with the evalbinop approach, then it should work as
> > > efficiently as my original proposal, while sacreficing the special cases
> > > that fold away the binop. I'm fine with either of the approaches.
> > > I scheduled a measurement
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/144327
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 113 of 113 matches
Mail list logo
