================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
