[New PM] Introducing PassInstrumentation framework
authorFedor Sergeev <fedor.sergeev@azul.com>
Thu, 20 Sep 2018 17:08:45 +0000 (17:08 +0000)
committerFedor Sergeev <fedor.sergeev@azul.com>
Thu, 20 Sep 2018 17:08:45 +0000 (17:08 +0000)
commitee8d31c49e12a4d1fc10940a8fa644e5351239ed
tree25f4ccfea83d1279d2e543a6349a4cea2e309015
parente23d0b636ca317347e84b3006a89eb185a130983
[New PM] Introducing PassInstrumentation framework

Pass Execution Instrumentation interface enables customizable instrumentation
of pass execution, as per "RFC: Pass Execution Instrumentation interface"
posted 06/07/2018 on llvm-dev@

The intent is to provide a common machinery to implement all
the pass-execution-debugging features like print-before/after,
opt-bisect, time-passes etc.

Here we get a basic implementation consisting of:
* PassInstrumentationCallbacks class that handles registration of callbacks
  and access to them.

* PassInstrumentation class that handles instrumentation-point interfaces
  that call into PassInstrumentationCallbacks.

* Callbacks accept StringRef which is just a name of the Pass right now.
  There were some ideas to pass an opaque wrapper for the pointer to pass instance,
  however it appears that pointer does not actually identify the instance
  (adaptors and managers might have the same address with the pass they govern).
  Hence it was decided to go simple for now and then later decide on what the proper
  mental model of identifying a "pass in a phase of pipeline" is.

* Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies
  on different IRUnits (e.g. Analyses).

* PassInstrumentationAnalysis analysis is explicitly requested from PassManager through
  usual AnalysisManager::getResult. All pass managers were updated to run that
  to get PassInstrumentation object for instrumentation calls.

* Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra
  args out of a generic PassManager's extra args. This is the only way I was able to explicitly
  run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or
  RepeatedPass::run.
  TODO: Upon lengthy discussions we agreed to accept this as an initial implementation
  and then get rid of getAnalysisResult by improving RepeatedPass implementation.

* PassBuilder takes PassInstrumentationCallbacks object to pass it further into
  PassInstrumentationAnalysis. Callbacks registration should be performed directly
  through PassInstrumentationCallbacks.

* new-pm tests updated to account for PassInstrumentationAnalysis being run

* Added PassInstrumentation tests to PassBuilderCallbacks unit tests.
  Other unit tests updated with registration of the now-required PassInstrumentationAnalysis.

  Made getName helper to return std::string (instead of StringRef initially) to fix
  asan builtbot failures on CGSCC tests.

Reviewers: chandlerc, philip.pfaffe
Differential Revision: https://reviews.llvm.org/D47858

llvm-svn: 342664
22 files changed:
llvm/include/llvm/Analysis/CGSCCPassManager.h
llvm/include/llvm/IR/PassInstrumentation.h [new file with mode: 0644]
llvm/include/llvm/IR/PassManager.h
llvm/include/llvm/Passes/PassBuilder.h
llvm/include/llvm/Transforms/Scalar/LoopPassManager.h
llvm/lib/Analysis/CGSCCPassManager.cpp
llvm/lib/FuzzMutate/IRMutator.cpp
llvm/lib/IR/CMakeLists.txt
llvm/lib/IR/PassInstrumentation.cpp [new file with mode: 0644]
llvm/lib/Passes/PassRegistry.def
llvm/lib/Transforms/Scalar/LoopPassManager.cpp
llvm/test/Other/loop-pm-invalidation.ll
llvm/test/Other/new-pass-manager.ll
llvm/test/Other/new-pm-defaults.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Transforms/Inline/cgscc-incremental-invalidate.ll
llvm/test/Transforms/LoopRotate/pr35210.ll
llvm/unittests/Analysis/CGSCCPassManagerTest.cpp
llvm/unittests/IR/PassBuilderCallbacksTest.cpp
llvm/unittests/IR/PassManagerTest.cpp
llvm/unittests/Transforms/Scalar/LoopPassManagerTest.cpp