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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
