Skip to content
  1. Nov 22, 2013
    • Chandler Carruth's avatar
      [PM] Remove the IRUnitT typedef requirement for analysis passes. · bf950c0f
      Chandler Carruth authored
      Since the analysis managers were split into explicit function and module
      analysis managers, it is now completely trivial to specify this when
      building up the concept and model types explicitly, and it is impossible
      to end up with a type error at run time. We instantiate a template when
      registering a pass that will enforce the requirement at a type-system
      level, and we produce a dynamic error on all the other query paths to
      the analysis manager if the pass in question isn't registered.
      
      llvm-svn: 195447
      bf950c0f
    • Chandler Carruth's avatar
      [PM] Fix the analysis templates' usage of IRUnitT. · 5bf5e31c
      Chandler Carruth authored
      This is supposed to be the whole type of the IR unit, and so we
      shouldn't pass a pointer to it but rather the value itself. In turn, we
      need to provide a 'Module *' as that type argument (for example). This
      will become more relevant with SCCs or other units which may not be
      passed as a pointer type, but also brings consistency with the
      transformation pass templates.
      
      llvm-svn: 195445
      5bf5e31c
    • Chandler Carruth's avatar
      [PM] Switch analysis managers to be threaded through the run methods · b3e72199
      Chandler Carruth authored
      rather than the constructors of passes.
      
      This simplifies the APIs of passes significantly and removes an error
      prone pattern where the *same* manager had to be given to every
      different layer. With the new API the analysis managers themselves will
      have to be cross connected with proxy analyses that allow a pass at one
      layer to query for the analysis manager of another layer. The proxy will
      both expose a handle to the other layer's manager and it will provide
      the invalidation hooks to ensure things remain consistent across layers.
      Finally, the outer-most analysis manager has to be passed to the run
      method of the outer-most pass manager. The rest of the propagation is
      automatic.
      
      I've used SFINAE again to allow passes to completely disregard the
      analysis manager if they don't need or want to care. This helps keep
      simple things simple for users of the new pass manager.
      
      Also, the system specifically supports passing a null pointer into the
      outer-most run method if your pass pipeline neither needs nor wants to
      deal with analyses. I find this of dubious utility as while some
      *passes* don't care about analysis, I'm not sure there are any
      real-world users of the pass manager itself that need to avoid even
      creating an analysis manager. But it is easy to support, so there we go.
      
      Finally I renamed the module proxy for the function analysis manager to
      the more verbose but less confusing name of
      FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
      what else to name these things. I'm expecting in the fullness of time to
      potentially have the complete cross product of types at the proxy layer:
      
      {Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
      
      (except for XAnalysisManagerXProxy which doesn't make any sense)
      
      This should make it somewhat easier to do the next phases which is to
      build the upward proxy and get its invalidation correct, as well as to
      make the invalidation within the Module -> Function mapping pass be more
      fine grained so as to invalidate fewer fuction analyses.
      
      After all of the proxy analyses are done and the invalidation working,
      I'll finally be able to start working on the next two fun fronts: how to
      adapt an existing pass to work in both the legacy pass world and the new
      one, and building the SCC, Loop, and Region counterparts. Fun times!
      
      llvm-svn: 195400
      b3e72199
  2. Nov 21, 2013
    • Chandler Carruth's avatar
      [PM] Widen the interface for invalidate on an analysis result now that · 2846e9ef
      Chandler Carruth authored
      it is completely optional, and sink the logic for handling the preserved
      analysis set into it.
      
      This allows us to implement the delegation logic desired in the proxy
      module analysis for the function analysis manager where if the proxy
      itself is preserved we assume the set of functions hasn't changed and we
      do a fine grained invalidation by walking the functions in the module
      and running the invalidate for them all at the manager level and letting
      it try to invalidate any passes.
      
      This in turn makes it blindingly obvious why we should hoist the
      invalidate trait and have two collections of results. That allows
      handling invalidation for almost all analyses without indirect calls and
      it allows short circuiting when the preserved set is all.
      
      llvm-svn: 195338
      2846e9ef
    • Chandler Carruth's avatar
      [PM] Add support for using SFINAE to reflect on an analysis's result · f6e9986a
      Chandler Carruth authored
      type and detect whether or not it provides an 'invalidate' member the
      analysis manager should use.
      
      This lets the overwhelming common case of *not* caring about custom
      behavior when an analysis is invalidated be the the obvious default
      behavior with no code written by the author of an analysis. Only when
      they write code specifically to handle invalidation does it get used.
      
      Both cases are actually covered by tests here. The test analysis uses
      the default behavior, and the proxy module analysis actually has custom
      behavior on invalidation that is firing correctly. (In fact, this is the
      analysis which was the primary motivation for having custom invalidation
      behavior in the first place.)
      
      llvm-svn: 195332
      f6e9986a
    • Chandler Carruth's avatar
      [PM] Add a module analysis pass proxy for the function analysis manager. · 851a2aa0
      Chandler Carruth authored
      This proxy will fill the role of proxying invalidation events down IR
      unit layers so that when a module changes we correctly invalidate
      function analyses. Currently this is a very coarse solution -- any
      change blows away the entire thing -- but the next step is to make
      invalidation handling more nuanced so that we can propagate specific
      amounts of invalidation from one layer to the next.
      
      The test is extended to place a module pass between two function pass
      managers each of which have preserved function analyses which get
      correctly invalidated by the module pass that might have changed what
      functions are even in the module.
      
      llvm-svn: 195304
      851a2aa0
  3. Nov 20, 2013
    • Chandler Carruth's avatar
      [PM] Add the preservation system to the new pass manager. · c0bfa8c2
      Chandler Carruth authored
      This adds a new set-like type which represents a set of preserved
      analysis passes. The set is managed via the opaque PassT::ID() void*s.
      The expected convenience templates for interacting with specific passes
      are provided. It also supports a symbolic "all" state which is
      represented by an invalid pointer in the set. This state is nicely
      saturating as it comes up often. Finally, it supports intersection which
      is used when finding the set of preserved passes after N different
      transforms.
      
      The pass API is then changed to return the preserved set rather than
      a bool. This is much more self-documenting than the previous system.
      Returning "none" is a conservatively correct solution just like
      returning "true" from todays passes and not marking any passes as
      preserved. Passes can also be dynamically preserved or not throughout
      the run of the pass, and whatever gets returned is the binding state.
      Finally, preserving "all" the passes is allowed for no-op transforms
      that simply can't harm such things.
      
      Finally, the analysis managers are changed to instead of blindly
      invalidating all of the analyses, invalidate those which were not
      preserved. This should rig up all of the basic preservation
      functionality. This also correctly combines the preservation moving up
      from one IR-layer to the another and the preservation aggregation across
      N pass runs. Still to go is incrementally correct invalidation and
      preservation across IR layers incrementally during N pass runs. That
      will wait until we have a device for even exposing analyses across IR
      layers.
      
      While the core of this change is obvious, I'm not happy with the current
      testing, so will improve it to cover at least some of the invalidation
      that I can test easily in a subsequent commit.
      
      llvm-svn: 195241
      c0bfa8c2
    • Chandler Carruth's avatar
      [PM] Make the function pass manager more regular. · d895e29e
      Chandler Carruth authored
      The FunctionPassManager is now itself a function pass. When run over
      a function, it runs all N of its passes over that function. This is the
      1:N mapping in the pass dimension only. This allows it to be used in
      either a ModulePassManager or potentially some other manager that
      works on IR units which are supersets of Functions.
      
      This commit also adds the obvious adaptor to map from a module pass to
      a function pass, running the function pass across every function in the
      module.
      
      The test has been updated to use this new pattern.
      
      llvm-svn: 195192
      d895e29e
    • Chandler Carruth's avatar
      [PM] Split the analysis manager into a function-specific interface and · ed1ffe01
      Chandler Carruth authored
      a module-specific interface. This is the first of many steps necessary
      to generalize the infrastructure such that we can support both
      a Module-to-Function and Module-to-SCC-to-Function pass manager
      nestings.
      
      After a *lot* of attempts that never worked and didn't even make it to
      a committable state, it became clear that I had gotten the layering
      design of analyses flat out wrong. Four days later, I think I have most
      of the plan for how to correct this, and I'm starting to reshape the
      code into it. This is just a baby step I'm afraid, but starts separating
      the fundamentally distinct concepts of function analysis passes and
      module analysis passes so that in subsequent steps we can effectively
      layer them, and have a consistent design for the eventual SCC layer.
      
      As part of this, I've started some interface changes to make passes more
      regular. The module pass accepts the module in the run method, and some
      of the constructor parameters are gone. I'm still working out exactly
      where constructor parameters vs. method parameters will be used, so
      I expect this to fluctuate a bit.
      
      This actually makes the invalidation less "correct" at this phase,
      because now function passes don't invalidate module analysis passes, but
      that was actually somewhat of a misfeature. It will return in a better
      factored form which can scale to other units of IR. The documentation
      has gotten less verbose and helpful.
      
      llvm-svn: 195189
      ed1ffe01
  4. Nov 17, 2013
  5. Nov 13, 2013
    • 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
  6. Nov 09, 2013
    • Chandler Carruth's avatar
      [PM] Start sketching out the new module and function pass manager. · 90a835d2
      Chandler Carruth authored
      This is still just a skeleton. I'm trying to pull together the
      experimentation I've done into committable chunks, and this is the first
      coherent one. Others will follow in hopefully short order that move this
      more toward a useful initial implementation. I still expect the design
      to continue evolving in small ways as I work through the different
      requirements and features needed here though.
      
      Keep in mind, all of this is off by default.
      
      Currently, this mostly exercises the use of a polymorphic smart pointer
      and templates to hide the polymorphism for the pass manager from the
      pass implementation. The next step will be more significant, adding the
      first framework of analysis support.
      
      llvm-svn: 194325
      90a835d2
    • Chandler Carruth's avatar
      Move the old pass manager infrastructure into a legacy namespace and · 7caea415
      Chandler Carruth authored
      give the files a legacy prefix in the right directory. Use forwarding
      headers in the old locations to paper over the name change for most
      clients during the transitional period.
      
      No functionality changed here! This is just clearing some space to
      reduce renaming churn later on with a new system.
      
      Even when the new stuff starts to go in, it is going to be hidden behind
      a flag and off-by-default as it is still WIP and under development.
      
      This patch is specifically designed so that very little out-of-tree code
      has to change. I'm going to work as hard as I can to keep that the case.
      Only direct forward declarations of the PassManager class are impacted
      by this change.
      
      llvm-svn: 194324
      7caea415
  7. Oct 31, 2013
  8. Jan 07, 2013
  9. Jan 02, 2013
    • Chandler Carruth's avatar
      Move all of the header files which are involved in modelling the LLVM IR · 9fb823bb
      Chandler Carruth authored
      into their new header subdirectory: include/llvm/IR. This matches the
      directory structure of lib, and begins to correct a long standing point
      of file layout clutter in LLVM.
      
      There are still more header files to move here, but I wanted to handle
      them in separate commits to make tracking what files make sense at each
      layer easier.
      
      The only really questionable files here are the target intrinsic
      tablegen files. But that's a battle I'd rather not fight today.
      
      I've updated both CMake and Makefile build systems (I think, and my
      tests think, but I may have missed something).
      
      I've also re-sorted the includes throughout the project. I'll be
      committing updates to Clang, DragonEgg, and Polly momentarily.
      
      llvm-svn: 171366
      9fb823bb
    • Chandler Carruth's avatar
      b034cb77
  10. Dec 08, 2012
  11. Dec 04, 2012
  12. Oct 08, 2012
  13. Jun 02, 2012
  14. Jul 12, 2011
    • Jay Foad's avatar
      Second attempt at de-constifying LLVM Types in FunctionType::get(), · b804a2b7
      Jay Foad authored
      StructType::get() and TargetData::getIntPtrType().
      
      llvm-svn: 134982
      b804a2b7
    • Bill Wendling's avatar
      Revert r134893 and r134888 (and related patches in other trees). It was causing · a78cd228
      Bill Wendling authored
      an assert on Darwin llvm-gcc builds.
      
      Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, li\
      ne 2067.
      etc.
      
      http://smooshlab.apple.com:8013/builders/llvm-gcc-i386-darwin9-RA/builds/2354
      
      --- Reverse-merging r134893 into '.':
      U    include/llvm/Target/TargetData.h
      U    include/llvm/DerivedTypes.h
      U    tools/bugpoint/ExtractFunction.cpp
      U    unittests/Support/TypeBuilderTest.cpp
      U    lib/Target/ARM/ARMGlobalMerge.cpp
      U    lib/Target/TargetData.cpp
      U    lib/VMCore/Constants.cpp
      U    lib/VMCore/Type.cpp
      U    lib/VMCore/Core.cpp
      U    lib/Transforms/Utils/CodeExtractor.cpp
      U    lib/Transforms/Instrumentation/ProfilingUtils.cpp
      U    lib/Transforms/IPO/DeadArgumentElimination.cpp
      U    lib/CodeGen/SjLjEHPrepare.cpp
      --- Reverse-merging r134888 into '.':
      G    include/llvm/DerivedTypes.h
      U    include/llvm/Support/TypeBuilder.h
      U    include/llvm/Intrinsics.h
      U    unittests/Analysis/ScalarEvolutionTest.cpp
      U    unittests/ExecutionEngine/JIT/JITTest.cpp
      U    unittests/ExecutionEngine/JIT/JITMemoryManagerTest.cpp
      U    unittests/VMCore/PassManagerTest.cpp
      G    unittests/Support/TypeBuilderTest.cpp
      U    lib/Target/MBlaze/MBlazeIntrinsicInfo.cpp
      U    lib/Target/Blackfin/BlackfinIntrinsicInfo.cpp
      U    lib/VMCore/IRBuilder.cpp
      G    lib/VMCore/Type.cpp
      U    lib/VMCore/Function.cpp
      G    lib/VMCore/Core.cpp
      U    lib/VMCore/Module.cpp
      U    lib/AsmParser/LLParser.cpp
      U    lib/Transforms/Utils/CloneFunction.cpp
      G    lib/Transforms/Utils/CodeExtractor.cpp
      U    lib/Transforms/Utils/InlineFunction.cpp
      U    lib/Transforms/Instrumentation/GCOVProfiling.cpp
      U    lib/Transforms/Scalar/ObjCARC.cpp
      U    lib/Transforms/Scalar/SimplifyLibCalls.cpp
      U    lib/Transforms/Scalar/MemCpyOptimizer.cpp
      G    lib/Transforms/IPO/DeadArgumentElimination.cpp
      U    lib/Transforms/IPO/ArgumentPromotion.cpp
      U    lib/Transforms/InstCombine/InstCombineCompares.cpp
      U    lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
      U    lib/Transforms/InstCombine/InstCombineCalls.cpp
      U    lib/CodeGen/DwarfEHPrepare.cpp
      U    lib/CodeGen/IntrinsicLowering.cpp
      U    lib/Bitcode/Reader/BitcodeReader.cpp
      
      llvm-svn: 134949
      a78cd228
  15. Jul 11, 2011
  16. Mar 31, 2011
  17. Oct 19, 2010
    • Owen Anderson's avatar
      Get rid of static constructors for pass registration. Instead, every pass... · 6c18d1aa
      Owen Anderson authored
      Get rid of static constructors for pass registration.  Instead, every pass exposes an initializeMyPassFunction(), which
      must be called in the pass's constructor.  This function uses static dependency declarations to recursively initialize
      the pass's dependencies.
      
      Clients that only create passes through the createFooPass() APIs will require no changes.  Clients that want to use the
      CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
      before parsing commandline arguments.
      
      I have tested this with all standard configurations of clang and llvm-gcc on Darwin.  It is possible that there are problems
      with the static dependencies that will only be visible with non-standard options.  If you encounter any crash in pass
      registration/creation, please send the testcase to me directly.
      
      llvm-svn: 116820
      6c18d1aa
  18. Aug 06, 2010
  19. Jul 13, 2010
  20. Apr 17, 2010
  21. Mar 13, 2010
  22. Jan 27, 2010
  23. Jan 26, 2010
  24. Jan 22, 2010
    • Chris Lattner's avatar
      Stop building RTTI information for *most* llvm libraries. Notable · 7ba0661f
      Chris Lattner authored
      missing ones are libsupport, libsystem and libvmcore.  libvmcore is
      currently blocked on bugpoint, which uses EH.  Once it stops using
      EH, we can switch it off.
      
      This #if 0's out 3 unit tests, because gtest requires RTTI information.
      Suggestions welcome on how to fix this.
      
      llvm-svn: 94164
      7ba0661f
  25. Aug 31, 2009
Loading