Skip to content
  • Chandler Carruth's avatar
    Introduce an AnalysisManager which is like a pass manager but with a lot · 74015a70
    Chandler Carruth authored
    more smarts in it. This is where most of the interesting logic that used
    to live in the implicit-scheduling-hackery of the old pass manager will
    live.
    
    Like the previous commits, note that this is a very early prototype!
    I expect substantial changes before this is ready to use.
    
    The core of the design is the following:
    
    - We have an AnalysisManager which can be used across a series of
      passes over a module.
    - The code setting up a pass pipeline registers the analyses available
      with the manager.
    - Individual transform passes can check than an analysis manager
      provides the analyses they require in order to fail-fast.
    - There is *no* implicit registration or scheduling.
    - Analysis passes are different from other passes: they produce an
      analysis result that is cached and made available via the analysis
      manager.
    - Cached results are invalidated automatically by the pass managers.
    - When a transform pass requests an analysis result, either the analysis
      is run to produce the result or a cached result is provided.
    
    There are a few aspects of this design that I *know* will change in
    subsequent commits:
    - Currently there is no "preservation" system, that needs to be added.
    - All of the analysis management should move up to the analysis library.
    - The analysis management needs to support at least SCC passes. Maybe
      loop passes. Living in the analysis library will facilitate this.
    - Need support for analyses which are *both* module and function passes.
    - Need support for pro-actively running module analyses to have cached
      results within a function pass manager.
    - Need a clear design for "immutable" passes.
    - Need support for requesting cached results when available and not
      re-running the pass even if that would be necessary.
    - Need more thorough testing of all of this infrastructure.
    
    There are other aspects that I view as open questions I'm hoping to
    resolve as I iterate a bit on the infrastructure, and especially as
    I start writing actual passes against this.
    - Should we have separate management layers for function, module, and
      SCC analyses? I think "yes", but I'm not yet ready to switch the code.
      Adding SCC support will likely resolve this definitively.
    - How should the 'require' functionality work? Should *that* be the only
      way to request results to ensure that passes always require things?
    - How should preservation work?
    - Probably some other things I'm forgetting. =]
    
    Look forward to more patches in shorter order now that this is in place.
    
    llvm-svn: 194538
    74015a70
Loading