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 fact, you can compare the threshold with the sum of complexity values of > the two operands to get a heuristic which is practically equivalent to the > complexity threshold that you want, but doesn't pass around `UnknownVal`s in > already complex code and doesn't introduce a new symbol kind.
I played with the idea and there is one wrinkle. EvalBinOp applies tactics that can reduce the requested operation to known values or ranges after applying some logic, like: - eagerly fold away multiplications to 1 - shifting 0 left or right to a cast - zero divided/modulo by some value to 0 - others By checking the sum of the operand complexities before applying these heuristics would mean that we would lose out on these benefits, thus reduce cases into `Unknown` while in the past we could have deduced a simple result for the case. The evalbinops use a bunch of APIs (call `makeSymExprValNN`, `makeNonLoc`, etc), so it's not easy to ensure that on all paths we obey the max complexity rule - unless we do the complexity check at `makeNonLoc`, where everything boils down to. This was the originally proposed version, which was rejected due to the fact that if `makeNonLoc` could return `Unknown` then a bunch of call-sites would need to be updated to accommodate for this. 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 evalbinop approach, and I expect the results by tomorrow the latest. 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
