This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Implement functionality to compare if two boolean values are equivalent.
ClosedPublic

Authored by wyt on Jun 24 2022, 5:51 AM.

Details

Summary

equivalentBoolValues compares equivalence between two booleans. The current implementation does not consider constraints imposed by flow conditions on the booleans and its subvalues.

Depends On D128520

Diff Detail

Event Timeline

wyt created this revision.Jun 24 2022, 5:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 5:51 AM
wyt requested review of this revision.Jun 24 2022, 5:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 5:51 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
wyt edited the summary of this revision. (Show Details)Jun 24 2022, 6:08 AM
sgatev added inline comments.Jun 24 2022, 6:45 AM
clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
140

This seems unrelated to flow conditions (is this intentional?) and a bit too specific for DataflowAnalysisContext. Perhaps we should expose the solver and let user code use it the way it needs to.

wyt added inline comments.Jun 24 2022, 7:05 AM
clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
140

This seems unrelated to flow conditions (is this intentional?) and a bit too specific for DataflowAnalysisContext. Perhaps we should expose the solver and let user code use it the way it needs to.

Yes, we noticed this. Unfortunately, creation and using of values is tightly tied to DataflowAnalysisContext currently, since the context is responsible for owning the values. @gribozavr2 and I were discussing about refactoring this logic out, some ideas we considered include

  1. A class responsible for communicating with the solver, responsible for building input and processing output from the solver. The context and this class would have a circular dependency. The context relies on this class to interface with the solver, the class relies on the context to create and use values.
  2. A further refactoring could be moving the ownership of Values into another object, e.g. a DataflowArena maybe. Objects which need Values would have this object as a field.

I chose to stick with this implementation for now and to consider the refactoring in a future patch so that pointer nullability analysis relying on buildAndSubstituteFlowCondition will not be blocked by this.

@gribozavr2: Please add if I missed something.
@all: Let me know your thoughts on this, and if you have any ideas as well.
Thanks!!

wyt updated this revision to Diff 439762.Jun 24 2022, 7:58 AM

Rename createIff to getOrCreateIff based on change in parent patch.

xazax.hun accepted this revision.Jun 24 2022, 9:08 AM
This revision is now accepted and ready to land.Jun 24 2022, 9:08 AM
gribozavr2 accepted this revision.Jun 24 2022, 2:31 PM
wyt updated this revision to Diff 439899.Jun 24 2022, 2:55 PM

Propagate change from parent patch.

This revision was landed with ongoing or failed builds.Jun 24 2022, 3:10 PM
This revision was automatically updated to reflect the committed changes.