Skip to content
  1. Mar 06, 2014
    • Ahmed Charles's avatar
      Replace OwningPtr<T> with std::unique_ptr<T>. · 56440fd8
      Ahmed Charles authored
      This compiles with no changes to clang/lld/lldb with MSVC and includes
      overloads to various functions which are used by those projects and llvm
      which have OwningPtr's as parameters. This should allow out of tree
      projects some time to move. There are also no changes to libs/Target,
      which should help out of tree targets have time to move, if necessary.
      
      llvm-svn: 203083
      56440fd8
  2. Mar 04, 2014
  3. Mar 02, 2014
  4. Feb 25, 2014
    • Rafael Espindola's avatar
      Fix resetting the DataLayout in a Module. · 248ac139
      Rafael Espindola authored
      No tool does this currently, but as everything else in a module we should be
      able to change its DataLayout.
      
      Most of the fix is in DataLayout to make sure it can be reset properly.
      
      The test uses Module::setDataLayout since the fact that we mutate a DataLayout
      is an implementation detail. The module could hold a OwningPtr<DataLayout> and
      the DataLayout itself could be immutable.
      
      Thanks to Philip Reames for pushing me in the right direction.
      
      llvm-svn: 202198
      248ac139
    • Rafael Espindola's avatar
      Make DataLayout a plain object, not a pass. · 93512512
      Rafael Espindola authored
      Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
      don't don't handle passes to also use DataLayout.
      
      llvm-svn: 202168
      93512512
  5. Feb 05, 2014
    • Chandler Carruth's avatar
      [PM] Don't require analysis results to be const in the new pass manager. · eedf9fca
      Chandler Carruth authored
      I think this was just over-eagerness on my part. The analysis results
      need to often be non-const because they need to (in some cases at least)
      be updated by the transformation pass in order to remain correct. It
      also makes lazy analyses (a common case) needlessly annoying to write in
      order to make their entire state mutable.
      
      llvm-svn: 200881
      eedf9fca
  6. Jan 22, 2014
    • Matt Arsenault's avatar
      Bug 18228 - Fix accepting bitcasts between vectors of pointers with a · fc3c91d0
      Matt Arsenault authored
      different number of elements.
      
      Bitcasts were passing with vectors of pointers with different number of
      elements since the number of elements was checking
      SrcTy->getVectorNumElements() == SrcTy->getVectorNumElements() which
      isn't helpful. The addrspacecast was also wrong, but that case at least
      is caught by the verifier. Refactor bitcast and addrspacecast handling
      in castIsValid to be more readable and fix this problem.
      
      llvm-svn: 199821
      fc3c91d0
  7. Jan 19, 2014
    • Chandler Carruth's avatar
      [PM] Make the verifier work independently of any pass manager. · 043949d4
      Chandler Carruth authored
      This makes the 'verifyFunction' and 'verifyModule' functions totally
      independent operations on the LLVM IR. It also cleans up their API a bit
      by lifting the abort behavior into their clients and just using an
      optional raw_ostream parameter to control printing.
      
      The implementation of the verifier is now just an InstVisitor with no
      multiple inheritance. It also is significantly more const-correct, and
      hides the const violations internally. The two layers that force us to
      break const correctness are building a DomTree and dispatching through
      the InstVisitor.
      
      A new VerifierPass is used to implement the legacy pass manager
      interface in terms of the other pieces.
      
      The error messages produced may be slightly different now, and we may
      have slightly different short circuiting behavior with different usage
      models of the verifier, but generally everything works equivalently and
      this unblocks wiring the verifier up to the new pass manager.
      
      llvm-svn: 199569
      043949d4
  8. Jan 13, 2014
    • Chandler Carruth's avatar
      [PM] Split DominatorTree into a concrete analysis result object which · 73523021
      Chandler Carruth authored
      can be used by both the new pass manager and the old.
      
      This removes it from any of the virtual mess of the pass interfaces and
      lets it derive cleanly from the DominatorTreeBase<> template. In turn,
      tons of boilerplate interface can be nuked and it turns into a very
      straightforward extension of the base DominatorTree interface.
      
      The old analysis pass is now a simple wrapper. The names and style of
      this split should match the split between CallGraph and
      CallGraphWrapperPass. All of the users of DominatorTree have been
      updated to match using many of the same tricks as with CallGraph. The
      goal is that the common type remains the resulting DominatorTree rather
      than the pass. This will make subsequent work toward the new pass
      manager significantly easier.
      
      Also in numerous places things became cleaner because I switched from
      re-running the pass (!!! mid way through some other passes run!!!) to
      directly recomputing the domtree.
      
      llvm-svn: 199104
      73523021
    • Chandler Carruth's avatar
      [cleanup] Move the Dominators.h and Verifier.h headers into the IR · 5ad5f15c
      Chandler Carruth authored
      directory. These passes are already defined in the IR library, and it
      doesn't make any sense to have the headers in Analysis.
      
      Long term, I think there is going to be a much better way to divide
      these matters. The dominators code should be fully separated into the
      abstract graph algorithm and have that put in Support where it becomes
      obvious that evn Clang's CFGBlock's can use it. Then the verifier can
      manually construct dominance information from the Support-driven
      interface while the Analysis library can provide a pass which both
      caches, reconstructs, and supports a nice update API.
      
      But those are very long term, and so I don't want to leave the really
      confusing structure until that day arrives.
      
      llvm-svn: 199082
      5ad5f15c
  9. Jan 12, 2014
  10. Jan 11, 2014
  11. Jan 07, 2014
    • Chandler Carruth's avatar
      Move the LLVM IR asm writer header files into the IR directory, as they · 9aca918d
      Chandler Carruth authored
      are part of the core IR library in order to support dumping and other
      basic functionality.
      
      Rename the 'Assembly' include directory to 'AsmParser' to match the
      library name and the only functionality left their -- printing has been
      in the core IR library for quite some time.
      
      Update all of the #includes to match.
      
      All of this started because I wanted to have the layering in good shape
      before I started adding support for printing LLVM IR using the new pass
      infrastructure, and commandline support for the new pass infrastructure.
      
      llvm-svn: 198688
      9aca918d
  12. Jan 05, 2014
  13. Jan 02, 2014
  14. Jan 01, 2014
  15. Dec 13, 2013
  16. Dec 10, 2013
  17. Dec 05, 2013
  18. Dec 02, 2013
    • Diego Novillo's avatar
      Fix dominator descendants for unreachable blocks. · ee592429
      Diego Novillo authored
      When a block is unreachable, asking its dom tree descendants should
      return the empty set. However, the computation of the descendants
      was causing a segmentation fault because the dom tree node we get
      from the basic block is initially NULL.
      
      Fixed by adding a test for a valid dom tree node before we iterate.
      
      The patch also adds some unit tests to the existing dom tree tests.
      
      llvm-svn: 196099
      ee592429
  19. Nov 26, 2013
    • Chandler Carruth's avatar
      [PM] Split the CallGraph out from the ModulePass which creates the · 6378cf53
      Chandler Carruth authored
      CallGraph.
      
      This makes the CallGraph a totally generic analysis object that is the
      container for the graph data structure and the primary interface for
      querying and manipulating it. The pass logic is separated into its own
      class. For compatibility reasons, the pass provides wrapper methods for
      most of the methods on CallGraph -- they all just forward.
      
      This will allow the new pass manager infrastructure to provide its own
      analysis pass that constructs the same CallGraph object and makes it
      available. The idea is that in the new pass manager, the analysis pass's
      'run' method returns a concrete analysis 'result'. Here, that result is
      a 'CallGraph'. The 'run' method will typically do only minimal work,
      deferring much of the work into the implementation of the result object
      in order to be lazy about computing things, but when (like DomTree)
      there is *some* up-front computation, the analysis does it prior to
      handing the result back to the querying pass.
      
      I know some of this is fairly ugly. I'm happy to change it around if
      folks can suggest a cleaner interim state, but there is going to be some
      amount of unavoidable ugliness during the transition period. The good
      thing is that this is very limited and will naturally go away when the
      old pass infrastructure goes away. It won't hang around to bother us
      later.
      
      Next up is the initial new-PM-style call graph analysis. =]
      
      llvm-svn: 195722
      6378cf53
  20. Nov 23, 2013
    • Chandler Carruth's avatar
      [PM] Complete the cross-layer interfaces with a Module-to-Function · c1ff9ed6
      Chandler Carruth authored
      proxy. This lets a function pass query a module analysis manager.
      However, the interface is const to indicate that only cached results can
      be safely queried.
      
      With this, I think the new pass manager is largely functionally complete
      for modules and analyses. Still lots to test, and need to generalize to
      SCCs and Loops, and need to build an adaptor layer to support the use of
      existing Pass objects in the new managers.
      
      llvm-svn: 195538
      c1ff9ed6
    • Chandler Carruth's avatar
      [PM] Rename TestAnalysisPass to TestFunctionAnalysis to clear the way · 2ad18583
      Chandler Carruth authored
      for a TestModuleAnalysis.
      
      llvm-svn: 195537
      2ad18583
    • Chandler Carruth's avatar
      [PM] Add support to the analysis managers to query explicitly for cached · de9afd84
      Chandler Carruth authored
      results.
      
      This is the last piece of infrastructure needed to effectively support
      querying *up* the analysis layers. The next step will be to introduce
      a proxy which provides access to those layers with appropriate use of
      const to direct queries to the safe interface.
      
      llvm-svn: 195525
      de9afd84
    • Chandler Carruth's avatar
      [PM] Switch the downward invalidation to be incremental where only the · bceeb229
      Chandler Carruth authored
      one function's analyses are invalidated at a time. Also switch the
      preservation of the proxy to *fully* preserve the lower (function)
      analyses.
      
      Combined, this gets both upward and downward analysis invalidation to
      a point I'm happy with:
      
      - A function pass invalidates its function analyses, and its parent's
        module analyses.
      - A module pass invalidates all of its functions' analyses including the
        set of which functions are in the module.
      - A function pass can preserve a module analysis pass.
      - If all function passes preserve a module analysis pass, that
        preservation persists. If any doesn't the module analysis is
        invalidated.
      - A module pass can opt into managing *all* function analysis
        invalidation itself or *none*.
      - The conservative default is none, and the proxy takes the maximally
        conservative approach that works even if the set of functions has
        changed.
      - If a module pass opts into managing function analysis invalidation it
        has to propagate the invalidation itself, the proxy just does nothing.
      
      The only thing really missing is a way to query for a cached analysis or
      nothing at all. With this, function passes can more safely request
      a cached module analysis pass without fear of it accidentally running
      part way through.
      
      llvm-svn: 195519
      bceeb229
  21. Nov 22, 2013
    • Chandler Carruth's avatar
      [PM] Teach the analysis managers to pass themselves as arguments to the · f2edc075
      Chandler Carruth authored
      run methods of the analysis passes.
      
      Also generalizes and re-uses the SFINAE for transformation passes so
      that users can write an analysis pass and only accept an analysis
      manager if that is useful to their pass.
      
      This completes the plumbing to make an analysis manager available
      through every pass's run method if desired so that passes no longer need
      to be constructed around them.
      
      llvm-svn: 195451
      f2edc075
    • 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
Loading