[clang] [clang][nullability] Don't discard expression state before end of full-expression. (PR #82611)

[via cfe-commits]

martinboehme wrote:

> I'm a little concerned with the complexity and cost required to support this optimization. With this added cost, do you know if the analysis still faster (and less SAT timeouts?) than if we just did the simple thing of not dropping state?

Yes, significantly faster and fewer SAT timeouts.

To compare against the alternative of not dropping state, I reverse-applied #72985, then ran benchmarks for the Crubit nullability check and looked at the number of SAT solver timeouts when running the nullability check on an internal codebase.

Benchmark results show that this patch ("old") performs significantly better than reverse-applied #72985 ("new"):

```
name                              old cpu/op   new cpu/op   delta
BM_PointerAnalysisCopyPointer     72.4µs ± 4%  71.0µs ± 4%   -1.94%  (p=0.006 n=19+19)
BM_PointerAnalysisIntLoop          191µs ± 3%   237µs ± 3%  +24.50%  (p=0.000 n=19+20)
BM_PointerAnalysisPointerLoop      326µs ± 3%   405µs ± 3%  +24.16%  (p=0.000 n=17+19)
BM_PointerAnalysisBranch           192µs ± 3%   186µs ± 4%   -3.26%  (p=0.000 n=20+20)
BM_PointerAnalysisLoopAndBranch    523µs ± 4%   690µs ± 5%  +31.95%  (p=0.000 n=20+20)
BM_PointerAnalysisTwoLoops         339µs ± 3%   445µs ± 2%  +31.49%  (p=0.000 n=20+20)
BM_PointerAnalysisJoinFilePath    1.62ms ± 3%  2.04ms ± 4%  +25.65%  (p=0.000 n=20+20)
BM_PointerAnalysisCallInLoop      1.15ms ± 4%  1.48ms ± 4%  +29.03%  (p=0.000 n=19+19)
```

Regarding SAT solver timeouts, on the codebase I looked at, reverse-applied #72985 results in over four times as many SAT solver timeouts as this patch. This is because reverse-applied #72985 performs joins on entries in `ExprToVal` that could simply have been discarded, and those joins often require calling the SAT solver.

I'll address the code-level comments next but wanted to get this high-level comment out first.

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