[all-commits] [llvm/llvm-project] bbcf11: [clang][dataflow] Weaken abstract comparison to en...

[Yitzhak Mandelbaum via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bbcf11f5af98a6e0fa008e180404cfc397f336fa
      https://github.com/llvm/llvm-project/commit/bbcf11f5af98a6e0fa008e180404cfc397f336fa
  Author: Yitzhak Mandelbaum <yitzhakm at google.com>
  Date:   2022-04-13 (Wed, 13 Apr 2022)

  Changed paths:
    M clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
    M clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
    M clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
    M clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

  Log Message:
  -----------
  [clang][dataflow] Weaken abstract comparison to enable loop termination.

Currently, when the framework is used with an analysis that does not override
`compareEquivalent`, it does not terminate for most loops. The root cause is the
interaction of (the default implementation of) environment comparison
(`compareEquivalent`) and the means by which locations and values are
allocated. Specifically, the creation of certain values (including: reference
and pointer values; merged values) results in allocations of fresh locations in
the environment. As a result, analysis of even trivial loop bodies produces
different (if isomorphic) environments, on identical inputs. At the same time,
the default analysis relies on strict equality (versus some relaxed notion of
equivalence). Together, when the analysis compares these isomorphic, yet
unequal, environments, to determine whether the successors of the given block
need to be (re)processed, the result is invariably "yes", thus preventing loop
analysis from reaching a fixed point.

There are many possible solutions to this problem, including equivalence that is
less than strict pointer equality (like structural equivalence) and/or the
introduction of an explicit widening operation. However, these solutions will
require care to be implemented correctly. While a high priority, it seems more
urgent that we fix the current default implentation to allow
termination. Therefore, this patch proposes, essentially, to change the default
comparison to trivally equate any two values. As a result, we can say precisely
that the analysis will process the loop exactly twice -- once to establish an
initial result state and the second to produce an updated result which will
(always) compare equal to the previous. While clearly unsound -- we are not
reaching a fix point of the transfer function, in practice, this level of
analysis will find many practical issues where a single iteration of the loop
impacts abstract program state.

Note, however, that the change to the default `merge` operation does not affect
soundness, because the framework already produces a fresh (sound) abstraction of
the value when the two values are distinct. The previous setting was overly
conservative.

Differential Revision: https://reviews.llvm.org/D123586