[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

[via cfe-commits]

================
@@ -311,7 +318,10 @@ computeBlockInputState(const CFGBlock &Block, AnalysisContext &AC) {
     }
   }
 
-  JoinedStateBuilder Builder(AC);
+  // When performing the join, only retain state for those expressions that are
+  // consumed by this block. This avoids performing joins and potentially
+  // extending the flow condition for expressions that we won't need anyway.
+  JoinedStateBuilder Builder(AC, AC.CFCtx.getExprConsumedByBlock(&Block));
----------------
martinboehme wrote:

> We have getStableStorageLocation that will first look up an expression in ExprToLoc and it will try to reuse the some location. In case we clear ExprToLoc along the back edge, in the second iteration through processing B2 we would create new locations for the expressions.

Confusingly, there are two different maps called `ExprToLoc`:

*  [`Environment::ExprToLoc`](https://github.com/llvm/llvm-project/blob/03f05a4e72891237264ab48adf62034aaac8bd46/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h#L661)

  This is the one from which this PR (and the simpler version in #72985) removes entries.

*  [`DataflowAnalysisContext::ExprToLoc`](https://github.com/llvm/llvm-project/blob/03f05a4e72891237264ab48adf62034aaac8bd46/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h#L218)

  This is the one used by [`DataflowAnalysisContext::getStableStorageLocation()`](https://github.com/llvm/llvm-project/blob/03f05a4e72891237264ab48adf62034aaac8bd46/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp#L86). This PR does not remove any entries from this map.

So the answer is that stable storage locations are not affected by this PR. If we have a storage location that is cleared from `Environment::ExprToLoc` as a result of this PR, then if we call `Environment::createStorageLocation(const Expr&)` on the next iteration, that will call through to `DataflowAnalysisContext::getStableStorageLocation()`, which will return the same storage location as it did on the previous iteration.

In the PR description, I merely used `ExprToLoc` as shorthand for `Environment::ExprToLoc` since that is the one that I'm concerned with most often -- but I realize this is potentially confusing.

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