[all-commits] [llvm/llvm-project] 25ac07: [clang][ASTImporter] Add isNewDecl

[Gabor Marton via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 25ac078a961de91522e5b5afaa6d4ffdd0dd05c4
      https://github.com/llvm/llvm-project/commit/25ac078a961de91522e5b5afaa6d4ffdd0dd05c4
  Author: Gabor Marton <gabor.marton at ericsson.com>
  Date:   2022-05-18 (Wed, 18 May 2022)

  Changed paths:
    M clang/include/clang/AST/ASTImporterSharedState.h
    M clang/lib/AST/ASTImporter.cpp
    M clang/unittests/AST/ASTImporterTest.cpp

  Log Message:
  -----------
  [clang][ASTImporter] Add isNewDecl

Summary:
Add a new function with which we can query if a Decl had been newly
created during the import process. This feature is a must if we want to
have a different static analysis strategy for such newly created
declarations.

This is a dependent patch that is needed for the new CTU implementation
discribed at
https://discourse.llvm.org/t/rfc-much-faster-cross-translation-unit-ctu-analysis-implementation/61728

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


  Commit: 56b9b97c1ef594f218eb06d2e62daa85cc238500
      https://github.com/llvm/llvm-project/commit/56b9b97c1ef594f218eb06d2e62daa85cc238500
  Author: Gabor Marton <gabor.marton at ericsson.com>
  Date:   2022-05-18 (Wed, 18 May 2022)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/CrossTU/CrossTranslationUnit.h
    M clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
    M clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
    M clang/lib/CrossTU/CrossTranslationUnit.cpp
    M clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
    M clang/lib/StaticAnalyzer/Core/CallEvent.cpp
    M clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
    M clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
    M clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
    M clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
    A clang/test/Analysis/Inputs/ctu-onego-existingdef-other.cpp
    A clang/test/Analysis/Inputs/ctu-onego-existingdef-other.cpp.externalDefMap.ast-dump.txt
    A clang/test/Analysis/Inputs/ctu-onego-indirect-other.cpp
    A clang/test/Analysis/Inputs/ctu-onego-indirect-other.cpp.externalDefMap.ast-dump.txt
    A clang/test/Analysis/Inputs/ctu-onego-small-other.cpp
    A clang/test/Analysis/Inputs/ctu-onego-small-other.cpp.externalDefMap.ast-dump.txt
    A clang/test/Analysis/Inputs/ctu-onego-toplevel-other.cpp
    A clang/test/Analysis/Inputs/ctu-onego-toplevel-other.cpp.externalDefMap.ast-dump.txt
    M clang/test/Analysis/analyzer-config.c
    M clang/test/Analysis/ctu-implicit.c
    M clang/test/Analysis/ctu-main.c
    M clang/test/Analysis/ctu-main.cpp
    M clang/test/Analysis/ctu-on-demand-parsing.c
    M clang/test/Analysis/ctu-on-demand-parsing.cpp
    A clang/test/Analysis/ctu-onego-existingdef.cpp
    A clang/test/Analysis/ctu-onego-indirect.cpp
    A clang/test/Analysis/ctu-onego-small.cpp
    A clang/test/Analysis/ctu-onego-toplevel.cpp

  Log Message:
  -----------
  [clang][analyzer][ctu] Make CTU a two phase analysis

This new CTU implementation is the natural extension of the normal single TU
analysis. The approach consists of two analysis phases. During the first phase,
we do a normal single TU analysis. During this phase, if we find a foreign
function (that could be inlined from another TU) then we don’t inline that
immediately, we rather mark that to be analysed later.
When the first phase is finished then we start the second phase, the CTU phase.
In this phase, we continue the analysis from that point (exploded node)
which had been enqueued during the first phase. We gradually extend the
exploded graph of the single TU analysis with the new node that was
created by the inlining of the foreign function.

We count the number of analysis steps of the first phase and we limit the
second (ctu) phase with this number.

This new implementation makes it convenient for the users to run the
single-TU and the CTU analysis in one go, they don't need to run the two
analysis separately. Thus, we name this new implementation as "onego" CTU.

Discussion:
https://discourse.llvm.org/t/rfc-much-faster-cross-translation-unit-ctu-analysis-implementation/61728

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


Compare: https://github.com/llvm/llvm-project/compare/fcfb86483b29...56b9b97c1ef5