================
@@ -339,6 +339,15 @@ void TransferFunctions::Visit(Stmt *S) {
AddLiveExpr(val.liveExprs, LV.ESetFact, CO->getFalseExpr());
return;
}
+ case Stmt::BinaryOperatorClass: {
+ auto const *BO = cast<BinaryOperator>(S);
+ if (BO->isLogicalOp()) {
----------------
NagyDonat wrote:
Very good point, although probably out of scope for this particular change,
because this change does not have a significant effect on the handling of these
strongly short-circuited expressions.
When we `Visit` the expression `true || b` or `false && a`, its non-const
operand was already marked as live before this change, because the default
behavior is that we mark all children of the statement as live. There might be
some logic that makes these dead sub-expressions completely inaccessible for
liveness, but I doubt that there is.
This commit only changes that in the combination of multiple short-circuiting
operators (e.g. `(b && b) || (b && b)` or a case like `(false && a) || b` that
involves a short-circuiting literal) visiting the top-level operator puts
liveness not only on its immediate children, but also on some deeper
sub-expressions. (The sub-expressions that are accessible through only
short-circuiting operators, e.g. visiting the `||` in `((a && b) == c) || d`
wouldn't mark `a` or `b` live because the recursion doesn't descend into the
`==`.) Here the only change is that the new code adds a liveness a bit earlier
in the backward sweep (i.e. the operand would remain live a bit longer during
the symbolic execution), but it's unchanged that it is marked as live at some
point.
(By the way this is mostly irrelevant for the path-sensitive analysis, because
we won't enter the CFGBlock that is "cut off" by the short-circuiting literal,
so the liveness of its sub-expression does not influence anything. Perhaps it
could influence things like leak reports? :thinking: )
I'm open to discussing this if you're interested, but in that case we should
probably move this discussion elsewhere.
https://github.com/llvm/llvm-project/pull/231419
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
