[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments
Stanislav Gatev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Jan 20 03:35:24 PST 2022
sgatev marked an inline comment as done.
sgatev added inline comments.
================
Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+ // in tests.
+ std::set<const CFGBlock *> Preds;
Preds.insert(Block.pred_begin(), Block.pred_end());
----------------
xazax.hun wrote:
> xazax.hun wrote:
> > Are we sure that the memory addresses of CFGBlocks are stable enough for a deterministic order? Alternatively, we could use the block ids for the ordering.
> Also, could you describe where the flakiness is originated from? Naively, I'd expect that the order in which we process the predecessors should not change the results of the analysis.
You're right, using block ids for ordering is better. I updated the code.
> Also, could you describe where the flakiness is originated from?
Say we have a block `B1` with predecessors `B2` and `B3`. Let the environment of `B2` after evaluating all of its statements is `B2Env = { Expr1 -> Loc1 }` and the environment of `B3` after evaluating all of its statement is `B3Env = { Expr2 -> Loc2 }` where `ExprX -> LocX` refers to a particular mapping of storage locations to expressions.
What we want for the input environment of `B1` is `{}` because `B2Env` and `B3Env` do not contain common assignments of storage locations to expressions. What we got before this patch is either `B2Env.join(B3Env) = { Expr1 -> Loc1 }` or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.
Without deterministic ordering of predecessors the test that I'm introducing in this patch is flaky.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D117754/new/
https://reviews.llvm.org/D117754
More information about the cfe-commits
mailing list