This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/Analysis/FlowSensitive/Transfer.h | ||
---|---|---|
28 | Depending on how willing sensitive we are to memory vs runtime, if there is one environment per basic block, we could look up the basic block of the statement, and use the basic block's id, to look up the environment in a vector. | |
clang/include/clang/Analysis/FlowSensitive/Value.h | ||
39 | Do we need Value in the Kind if we are already in the class Value? | |
79 | Do we want to have a separate class for every binary/unary operator? Alternatively, we could follow what the AST is already doing. Having BinaryOperator and UnaryOperator classes with a kind. I guess the current approach is not too bad for booleans, but if we want to support all integer operators as well in the future I wonder if that would end up with too much boilerplate. | |
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
98 | I wonder if this GetOrCreateFresh style operations will be common enough to have a helper for this purpose. |
clang/include/clang/Analysis/FlowSensitive/Transfer.h | ||
---|---|---|
28 | Whoops, never mind. The implementation already reflects what I suggested. |
Address reviewers' comments.
clang/include/clang/Analysis/FlowSensitive/Value.h | ||
---|---|---|
39 | We don't need the Value suffix in Kind and we don't expect other conjunctions, disjunctions, and negations for now so I simplified the names. | |
79 | Great point! Right now we have this subdivision only for booleans and, as you mentioned, it's not too bad. Definitely worth considering the alternative design going forward. If you don't mind, I suggest starting with the current setup, with a FIXME to remind us of the other option. I'd be happy to revisit this after the next couple of patches. | |
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
98 | That, or we can ensure that each expression gets assigned a value. Added a FIXME for now. |
Depending on how willing sensitive we are to memory vs runtime, if there is one environment per basic block, we could look up the basic block of the statement, and use the basic block's id, to look up the environment in a vector.