[clang] [analyzer] Enforce not making overly complicated symbols (PR #144327)
DonĂ¡t Nagy via cfe-commits
cfe-commits at lists.llvm.org
Fri Jun 27 06:52:05 PDT 2025
NagyDonat wrote:
> We see a lot of `simplifySValOnce` that decomposes the symbol and traverses the tree. With my original patch it's not present likely because the `Unknowns` poison the the tree so there is nothing to be traversed. This is why with my original patch we actually improve the performance of the sample rather than pessimising it.
Oh wait a minute... which symbol is entered by the `simplifySValOnce` calls? I'm pretty sure that the simplification process _cannot_ enter the complex structure in the `SymbolOverlyComplex` because its internal structure is private implementation detail -- so the only difference between the `SymbolOverlyComplex` and the `UnknownVal` is that `evalBinOp` (the parent stack frame in your flame graph) special cases `UnknownVal`:
```c++
SVal SValBuilder::evalBinOp(ProgramStateRef state, BinaryOperator::Opcode op,
SVal lhs, SVal rhs, QualType type) {
if (lhs.isUndef() || rhs.isUndef())
return UndefinedVal();
if (lhs.isUnknown() || rhs.isUnknown())
return UnknownVal();
// ... nontrivial part of the function
}
```
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`.
If you really want to bother with performance improvements that specifically target this 0.05% of the entrypoints, then you can insert one more early return here at the beginning of `evalBinOp` to skip some calculations if you encounter a `SymbolOverlyComplex`.
https://github.com/llvm/llvm-project/pull/144327
More information about the cfe-commits
mailing list