[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:

Did want to reply to this code-level comment, as it's somewhat relevant to the higher-level discussion.

> What about expressions that are consumed by a successor of this block? Is it OK to drop those?

Just to clarify what you're asking, let's assume we have a CFG with three blocks:

```
B1 -> B2 -> B3
```

Let's say we're currently processing B2. We're dropping all expressions from the environment that aren't consumed by B2.

I think you're asking: What about expressions that are consumed by B3? Presumably, we shouldn't drop those, as B3 will need them?

I think the answer is that this situation can't happen. If there's an edge between two expressions, I believe that there's also an edge between the blocks containing those expressions.

I have to admit, I'm not 100% sure whether this is true for the case of short-circuiting logical operators. We've already [noted](https://discourse.llvm.org/t/cfg-structure-for-short-circuiting-logical-operators/70775) before that the CFG structure for logical operators is a bit strange, so we might also anticipate more strangeness here. In any case, however, the framework already has specific code for logical operators to extract their operands from the environment for the block in which those operands were computed (rather than the current environment); see also my comment above.

All of this may become moot if we decide to go with the alternative implementation I proposed above, but I did want to respond to this point as it seemed relevant.

> Also, depending on the answer to these questions, this almost sounds like "live expressions analysis". In case this is related, we might want to use terminology from that as opposed to "consumed".

I think we won't need to go that far (fortunately) -- see above.

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