[clang] [analyzer] Enforce not making overly complicated symbols (PR #144327)

[Donát Nagy via cfe-commits]

NagyDonat wrote:

> Let me know if you means something like this when you referred to "you can insert one more early return".

Yes, I thought about something like your code example.

> > 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`.
> 
> This is the point. I don't think I can special case these because the computations still make sense to do.
> [...]
> Btw this would solve the performance problem (at least on the sample I shared), and it's technically a correct implementation, but I still find it unfair.

The whole "place a limit on symbol complexity" logic is a fundamentally _unfair_ heuristic that stops some calculations that "make sense" and are theoretically similar to other calculations.

Generally speaking, I'm trying to follow the dichotomy that:
- The normal, commonly occurring situation should be handled by effective and elegant code that runs quickly and produces many useful and accurate results -- even if this requires lots of code complexity.
- The rare corner cases should be short-circuited by simple logic, sacrificing theoretical elegance and accepting false negatives. (Even some performance hits are acceptable if they are overall negligible.)

https://github.com/llvm/llvm-project/pull/144327